MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. Cómo resolver el Error DCOM 10016 en Windows Server 2019: guía completa y opciones de mitigación

Cómo resolver el Error DCOM 10016 en Windows Server 2019: guía completa y opciones de mitigación

Windows Server

En entornos corporativos, pocos mensajes generan tanta confusión como el Error DCOM 10016. Ver decenas —o hasta cientos— de entradas por segundo puede hacer pensar que el servidor está a punto de fallar. La buena noticia: casi siempre es un falso positivo que se puede mitigar fácilmente.

Índice

¿Qué es DCOM y por qué aparece el Error 10016?

DCOM (Distributed Component Object Model) es la capa que permite que componentes software intercambien datos entre procesos o equipos. Windows Server registra el ID 10016 cuando una aplicación intenta iniciar (“Launch”) o activar (“Activation”) otro componente sin tener los permisos de seguridad adecuados. El mensaje revela:

  • CLSID afectado: {0358B920‑0AC7‑461F‑98F4‑58E32CD89148}
  • APPID afectado: {3EB3C877‑1F16‑487C‑9050‑104DBCD66683}
  • Cuenta solicitante: normalmente NT AUTHORITY\NETWORK SERVICE

Ese CLSID corresponde a la tarea programada de mantenimiento WinInet CacheTask, responsable de limpiar cachés HTTP del sistema. El propio Windows lo invoca de manera silenciosa; por eso los eventos surgen aun en instalaciones “limpias”.

Impacto real en producción

Pese a la avalancha de entradas, Microsoft clasifica este comportamiento como “por diseño”. El componente lanza la llamada, no obtiene la respuesta y Windows registra la discrepancia. Sin embargo:

  • No degrada el rendimiento de red ni de disco.
  • No detiene servicios críticos.
  • No provoca reinicios ni crashes.
  • La funcionalidad de WinInet CacheTask se completa de todas formas mediante rutas alternativas.

En la práctica, el riesgo es más ruido de auditoría que fallo operativo. Aun así, algunos equipos de cumplimiento exigen bitácoras sin advertencias. Para ellos existen varias estrategias.

Estrategias de mitigación

OpciónDescripciónCuándo aplicarla
No hacer nada (recomendación oficial)Microsoft señala que el evento es inofensivo. Al aceptarlo, se evita tocar la seguridad interna de DCOM.Cuando el servidor funciona con normalidad y solo preocupa la “contaminación” del log.
Ocultar los eventosCrear un filtro personalizado en el Visor de eventos y editar el XML para excluir el ID 10016. Así se limpian los informes sin alterar permisos.Cuando se requieren bitácoras legibles pero se desea una solución sin privilegios elevados.
Conceder permisos DCOMAñadir la cuenta NETWORK SERVICE con derecho de Local Activation al APPID afectado mediante dcomcnfg. El evento deja de generarse.Solo si es imprescindible eliminar la advertencia. Conlleva cambios en la ACL y necesita cuenta de administrador.

Procedimiento detallado para conceder permisos DCOM

  1. Identificar CLSID y APPID
    En el Visor de eventos, abra el error 10016 y copie ambos identificadores. Anótelos cuidadosamente.
  2. Abrir Component Services
    Pulse Win + R, escriba dcomcnfg y presione Enter. Navegue a Component Services › Computers › My Computer › DCOM Config.
  3. Localizar el APPID
    Cambie a la vista por Aplicación. Si no se muestra un nombre “amigable”, active View › Detail y ordene por App ID hasta hallar {3EB3C877‑…}. Suele aparecer como “WinInet CacheTask”.
  4. Tomar posesión (si es necesario)
    En algunos servidores, la pestaña Security está deshabilitada. Abra regedit.exe, busque la clave HKEYCLASSESROOT\APPID\{3EB3C877-…}, vaya a Permissions, pulse Advanced y tome posesión con un usuario Administrators. Acepte y cierre el editor.
  5. Editar permisos de inicio y activación
    Regrese a dcomcnfg. En Security › Launch and Activation Permissions seleccione Customize y luego Edit. Presione Add, escriba NETWORK SERVICE, confirme y marque Local Activation. No seleccione Remote Activation salvo necesidad expresa.
  6. Guardar y reiniciar
    Aplique los cambios. Para que surtan efecto, reinicie la tarea WinInet CacheTask o, de forma conservadora, el propio servidor fuera de horario de producción.
  7. Verificar
    Transcurridos 15 – 30 minutos, abra nuevamente el Visor de eventos; el contador de 10016 debería permanecer en 0. Si reaparece, revise que no existan políticas de grupo que sobrescriban la ACL.

Buenas prácticas antes y después de modificar DCOM

  • Respaldar el registro con reg export de los nodos modificados.
  • Documentar quién hizo el cambio, fecha, motivo y valores anteriores.
  • Probar primero en un entorno de ensayo idéntico al de producción.
  • Usar Process Monitor o el DCOMCNFG tracing solo si continúan los eventos para identificar otros CLSID.
  • Habilitar auditoría de objetos en la GPO para recoger quién dispara WinInet CacheTask.
  • Mantener un baselining semanal del Visor de eventos, de modo que cualquier desviación futura sea evidente.

Preguntas frecuentes

¿El evento 10016 puede ralentizar mi servidor?

No. La generación de entradas consume recursos insignificantes. El cuello de botella estaría en el disco si el log alcanza tamaños descomunales, pero el Observador rota archivos automáticamente.

¿Debo conceder permisos si uso IIS o SQL Server?

En general, no. Estos roles utilizan otros CLSID. Deje la configuración predeterminada y actúe solo si un servicio propio muestra errores correlacionados en el mismo rango horario.

¿Cómo puedo monitorizar que el cambio no ha introducido vulnerabilidades?

Ejecute un escáner de superficie como Microsoft Defender for Endpoint o Nessus. Busque específicamente aumentos en superficie de ataque DCOM. En la mayoría de los casos, añadir NETWORK SERVICE con privilegios mínimos no eleva el riesgo.

Conclusión

El Error DCOM 10016 en Windows Server 2019 es más una molestia que una amenaza. Evaluar la criticidad de sus registros y las políticas internas de auditoría determinará el camino a seguir. Para la inmensa mayoría de administradores, aceptar el evento o filtrarlo aporta el mejor equilibrio entre seguridad y practicidad. Solo si los requisitos de conformidad son extremadamente estrictos —o si una aplicación lo exige— vale la pena conceder permisos DCOM de forma controlada. Siguiendo los pasos anteriores tendrá un entorno estable, silencioso y plenamente documentado.

Anexo A — Referencia detallada de permisos DCOM

DCOM dispone de cuatro tipos de permisos: Launch Permission, Activation Permission, Access Permission y Configuration Permission. Para el evento 10016 nos conciernen los dos primeros. A continuación se describe cada uno:

  • Launch Permission: controla si un proceso puede iniciar la ejecución de un servidor COM fuera de su contexto. Local Launch y Remote Launch son subnodos.
  • Activation Permission: define si un cliente puede activar un objeto en un servidor COM ya en ejecución. Se divide en Local Activation y Remote Activation.
  • Access Permission: autoriza al proceso a llamar a métodos expuestos por el servidor COM una vez que se ha iniciado.
  • Configuration Permission: determina quién puede ajustar los parámetros del servidor COM a través de dcomcnfg.

Para la tarea WinInet CacheTask, el componente ya está configurado para Local Launch por cuenta de sistema. La falla surge en Local Activation, que NETWORK SERVICE no posee. Modificar únicamente esa casilla mantiene un modelo de privilegio mínimo.

Anexo B — Filtrar eventos 10016 sin herramientas externas

  1. Abra el Visor de eventos y seleccione Custom Views › Administrative Events.
  2. Haga clic en Filter Current Log… y cambie a la pestaña XML.
  3. Marque Edit query manually y agregue la condición: <Suppress><EventID>10016</EventID></Suppress> Inserte esa línea dentro del nodo <Query>.
  4. Guarde la vista como “Sin DCOM 10016”.
  5. Opcional: exporte la vista a .evtx para aplicarla a otros servidores mediante un script PowerShell.

Anexo C — Automatización via PowerShell

Si administra docenas de servidores, repasar cada GUI resulta inviable. La siguiente función simplifica el proceso (extracto ilustrativo):

function Grant-DComPermission {
    param(
        [string]$AppID = '3EB3C877-1F16-487C-9050-104DBCD66683',
        [string]$Account = 'NT AUTHORITY\NETWORK SERVICE'
    )
    $sid = New-Object System.Security.Principal.SecurityIdentifier(
        (New-Object System.Security.Principal.NTAccount($Account)).Value
    )
    $regPath = "HKCR:\AppID\{$AppID}"
    $launchPerm = Get-ItemProperty -Path $regPath -Name LaunchPermission -ErrorAction SilentlyContinue
    if (-not $launchPerm) { Write-Warning 'LaunchPermission not found'; return }
    # Aquí se implementa la lógica para añadir el SID con Local Activation.
}

Se sugiere ejecutarlo con -WhatIf para validar resultados antes de aplicarlos masivamente.

Anexo D — Política de grupo y reversión

Modificar manualmente DCOM puede ser sobreescrito por una directiva de grupo (Computer Configuration › Policies › Administrative Templates › Component Services). Para garantizar persistencia:

  • Crear una GPO Presidencial de “Conceder NETWORK SERVICE – Local Activation” al APPID.
  • Vincularla con Enforced (si se debe priorizar sobre otras GPO).
  • Documentar la reversión: basta con deshabilitar la GPO y forzar gpupdate /force.

Anexo E — Revisión posterior a parches

Después de cada Patch Tuesday, revise los CLSID y APPID implicados; es infrecuente pero posible que Microsoft cambie el comportamiento interno del programador de tareas. Mantenga un registro histórico que indique la fecha, número de compilación y estado del evento para detectar regresiones rápidamente.

Windows Server
Windows Server 2019 DCOM DistributedCOM Error 10016 Eventos de Windows
Índice