Tras el despliegue de la actualización acumulativa de abril (KB5036899) en Windows Server 2016, numerosos administradores han reportado que varios servicios críticos dejan de iniciarse arrojando el mensaje Error 1068: The dependency service or group failed to start. A continuación encontrarás un análisis en profundidad, métodos de diagnóstico paso a paso y soluciones prácticas para restaurar la operatividad de tu plataforma sin sacrificar la seguridad.
Contexto técnico del problema
Windows Server 2016 sigue recibiendo parches de seguridad «Cumulative Updates» orientados a mitigar vulnerabilidades de sistema y fortalecer la pila de TLS. El paquete KB5036899 introduce cambios en el manejador de control de servicios (SCM) y actualizaciones en la protección de credenciales de LSASS. No obstante, un conflicto en la carga de dependencias provoca que servicios que se inician en modo Automatic (Delayed Start) no encuentren activos a sus predecesores y terminen detenidos.
Síntomas frecuentes
- Servicios como
DHCP Server,W3SVC,Print Spooler,SQL ServeroNetlogonpermanecen en estado Stopped. - El Visor de eventos registra IDs 7001, 7009 y 7023 relativos a fallos de dependencia y expiración de tiempo de espera.
- Reinicios repetidos del host no resuelven la incidencia.
- Al usar
sc start <Servicio>aparece «Dependency service failed to start».
Matriz de respuesta rápida
| Acción | Detalles |
|---|---|
| Desinstalar la actualización | Ejecuta en un símbolo elevado:wusa /uninstall /kb:5036899 /quiet /norestarto bien: dism /online /remove-package /packageName:PackageforKB5036899Reinicia el servidor una vez concluido. |
| Bloquear la reinstalación automática | En Windows Update selecciona «Pausar actualizaciones» durante 7 días o el plazo que tu política permita. En entornos administrados con WSUS marca el parche como Declined. Con PowerShell:Hide-WindowsUpdate -KBArticleID 5036899 -Verbose |
| Comprobar dependencias de servicios | Abre services.msc y localiza el servicio fallido. En la pestaña Dependencies identifica la cadena completa. Inicia manualmente los servicios base en orden; a menudo basta con arrancar RPCSS o HTTP Service. |
| Monitorear futuras revisiones | Microsoft suele publicar «OOB Updates» cuando confirma un fallo generalizado. Suscríbete al canal Windows Release Health en el Centro de Administración. Valida siempre las revisiones en un entorno de preproducción. |
| No hay advertencia oficial aún | A la fecha de este artículo el estado de la página de salud de Windows no lista KB5036899 como «Known Issue». Por tanto, la vigilancia proactiva recae en el administrador. |
Diagnóstico detallado paso a paso
1. Revisar el Visor de eventos
Filtra el Log System por ID 7001, 7009, 7034 y determina qué servicio inició la cascada de fallos. La línea «The service XYZ depends on the ABC service which failed to start» revela la dependencia rota.
2. Validar la pila de servicios base
Ejecuta:
sc query type= service state= inactive | findstr /I /C:"SERVICE_NAME"y arranca uno por uno los servicios imprescindibles (TCP/IP, RPC, HTTP), verificando si su estado cambia correctamente a RUNNING.
3. Comprobar integridad de archivos del sistema
sfc /scannow
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /restorehealth
Un conflicto en bibliotecas compartidas puede aparecer tras la actualización; Dism reinyecta componentes limpios desde WinSxS.
4. Analizar el registro de setup de Windows Update
En C:\Windows\Logs\CBS\CBS.log busca líneas con «Error 0x800F0922» o «Failed to finalize» para detectar incoherencias durante la instalación del paquete.
Estrategias de prevención a medio y largo plazo
Entorno de staging y bancos de pruebas
Mantén un clúster o VM que replique tu producción al 80 %. Instala allí cada Patch Tuesday y somete las cargas críticas a pruebas funcionales (login, impresión, backup, replicación, etc.). Si el staging permanece operativo 24 h, autoriza la implementación en producción.
Política de actualización controlada
- WSUS: aprueba parches manualmente y delega la instalación a grupos de equipos subordinados.
- Windows Update for Business: define un anillo «Sacrificial» con deferencias de 7 días y uno «Broad» con deferencias de 14 días.
- PowerShell Desired State Configuration (DSC): controla versiones de paquetes y aplica rollbacks automatizados si la comprobación de salud falla.
Seguridad vs. disponibilidad
Desinstalar un parche de seguridad siempre expone temporalmente a CVEs recientes. Compensa ese riesgo restrictivo de la superficie de ataque:
- Aísla los servidores afectados en VLANs internas sin salida a internet.
- Activa reglas de firewall de reputación de IP.
- Endurece políticas de contraseña y auditorías de inicio de sesión.
Backups y puntos de restauración
Antes de cada ciclo de parches ejecuta:
wbadmin start backup -backupTarget:\\NAS\Backups -include:C:,D: -quieto usa tu plataforma de backup empresarial. Asegúrate de contar con dos copias almacenadas fuera del site principal. Si tu ventana de mantenimiento es reducida, crea un System State Backup para recuperar el registro y los archivos críticos de OS.
Automatización de mitigación con secuencias PowerShell
En dominios extensos (≥100 hosts) la mitigación manual no es viable. Utiliza un script que:
- Detecte si KB5036899 está presente:
- Desinstale el paquete y reinicie si procede.
- Envíe un registro a un collector Syslog o Azure Monitor.
$KB = "KB5036899"
$Servers = Get-Content .\ServerList.txt
foreach ($Server in $Servers) {
Invoke-Command -ComputerName $Server -ScriptBlock {
param($KB)
if (Get-HotFix -Id $KB -ErrorAction SilentlyContinue) {
wusa.exe /uninstall /kb:$KB /quiet /norestart
Restart-Computer -Force
}
} -ArgumentList $KB
}Preguntas frecuentes
¿Puedo desactivar servicios afectados en lugar de desinstalar el parche? No. Detener servicios críticos como Netlogon o DNS Server implica pérdida de autenticación y resolución de nombres. La desinstalación es la única vía segura de restaurar la funcionalidad. ¿El problema impacta a Windows 10 1607 LTSC? Las imágenes LTSC comparten cierta base de código con Server 2016, pero hasta ahora no se han reportado eventos 1068 masivos en estaciones LTSC. ¿Cuándo lanzará Microsoft un hotfix? Históricamente, la compañía publica parches fuera de banda en 3‑7 días si detecta afectación elevada. Mantente atento al Panel de Salud de Windows.
Conclusión
El error 1068 desencadenado por KB5036899 demuestra la importancia de los despliegues escalonados y las pruebas en entornos de staging. Mientras Microsoft libera una corrección oficial, la estrategia más segura es revertir el parche, bloquear su reinstalación y monitorizar los avisos del fabricante. Al adoptar una política de actualización controlada, copias de seguridad verificadas y scripts de mitigación, tu infraestructura podrá superar incidentes similares sin comprometer la continuidad operativa.