Netlogon o Workstation no se inician: diagnóstico y solución segura en Windows

Cuando los servicios Netlogon y Workstation (LanmanWorkstation) permanecen en estado Detenido o no pueden iniciarse, el inicio de sesión en dominio, la resolución de nombres NetBIOS y el acceso a recursos compartidos pueden fallar, provocando desconexiones generales, políticas de grupo que no se aplican y errores de confianza entre estaciones y controladores de dominio. A continuación se describe un procedimiento exhaustivo para detectar la causa y recuperar la funcionalidad sin comprometer la seguridad del sistema.

Índice

Síntomas que confirman el problema

  • Al arrancar el equipo se reciben eventos 7000 / 7001 (Service Control Manager) en el Visor de eventos indicando El servicio Workstation no pudo iniciarse debido al error de dependencia.
  • Inicios de sesión contra el dominio tardan varios minutos o devuelven No se puede encontrar el nombre de dominio.
  • Compartir archivos o impresoras con otros equipos aparece con el error No se puede encontrar la ruta de red (0x35).
  • Los comandos net use y nltest /dsgetdc: fallan con status 1355.

Identificar las dependencias de servicio

El primer paso es confirmar qué controlador o servicio evita que Netlogon/Workstation arranquen:

sc.exe qc lanmanworkstation
sc.exe qc bowser
sc.exe qc mrxsmb10
sc.exe qc mrxsmb20
sc.exe qc nsi

La salida muestra la lista de dependencias y su estado (STATE). Si mrxsmb10 (SMB v1) aparece deshabilitado (STOPPED o DISABLED) mientras Netlogon y Workstation siguen detenidos, se confirma que SMB v1 es la causa inmediata.

¿Por qué SMB v1 influye en Netlogon y Workstation?

El controlador mrxsmb10.sys pertenece a SMB v1. En versiones antiguas de Windows era obligatorio para la pila de red, por lo que muchos sistemas heredados todavía lo declaran en la matriz de dependencias. Cuando la organización decidió deshabilitar SMB v1 —acción recomendada desde 2017— es posible que se eliminara o pusiera en START= DISABLED. Algunos equipos, sin embargo, conservan la dependencia pero no la versión revisada del servicio Workstation que prescinde de ella, generando un bloqueo circular: el servicio pide un controlador inexistente.

Solución rápida (temporal): habilitar mrxsmb10

Para entornos donde la disponibilidad del servicio es crítica y se requiere un restablecimiento inmediato:

sc.exe config mrxsmb10 start= auto
shutdown /r /t 0

Tras reiniciar, comprueba el estado:

sc.exe query lanmanworkstation
sc.exe query netlogon

Si ambos servicios se muestran en RUNNING, los recursos compartidos y la unión al dominio volverán a funcionar.

Riesgos de seguridad al activar SMB v1

  • Exposición a vulnerabilidades como EternalBlue, ransomware y ataques de gusanos.
  • Falta de cifrado de sesión y firma digital por defecto.
  • No compatible con opciones de endurecimiento modernas (SMB Hardening).

Por ello, se recomienda emplear SMB v1 únicamente como salvaguarda provisional en redes aisladas o tras aplicar filtros de firewall restrictivos (allowlist de estaciones concretas).

Método recomendado: eliminar la dependencia sin restaurar SMB v1

El enfoque seguro consiste en editar las dependencias del servicio Workstation. Microsoft distribuyó versiones actualizadas de srvsvc.dll que ya no exigen mrxsmb10; sin embargo, ciertos parches no se instalaron o se revirtieron durante migraciones.

  1. Confirma que el registro de dependencias contiene a mrxsmb10:
    Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\lanmanworkstation' | Select-Object DependOnService
  2. Si aparece mrxsmb10, respáldalo y elimínalo:
    $path = 'HKLM:\SYSTEM\CurrentControlSet\Services\lanmanworkstation' $new = (Get-ItemProperty $path).DependOnService | Where-Object { $_ -ne 'mrxsmb10' } Set-ItemProperty -Path $path -Name DependOnService -Value $new
  3. Asegúrate de que SMB v2/v3 está habilitado:
    Enable-WindowsOptionalFeature -Online -FeatureName SMB2Protocol -NoRestart
  4. Instala las actualizaciones acumulativas más recientes.
  5. Reinicia el equipo y comprueba de nuevo con sc query.

Procedimiento de diagnóstico ampliado paso a paso

AcciónComando o herramientaResultado esperado
Analizar registrosVisor de eventos → System (eventvwr.msc)Eventos 7000‒7009 con detalles de error
Verificar integridad de archivossfc /scannowWindows Resource Protection did not find any integrity violations
Reparar imagen de sistemaDISM /Online /Cleanup-Image /RestoreHealthOperación completada correctamente
Revisar controladores críticosdriverquery /v | findstr SMBmrxsmb20.sys activo, mrxsmb10.sys ausente o detenido
Comprobar estado de redipconfig /all, nslookup, nltestResolución de DNS correcta; DCs accesibles

Automatizar la reparación con PowerShell

Para entornos con decenas o cientos de clientes afectados, la siguiente función puede integrarse en un script de inicio de sesión o ejecutarse mediante Remote PowerShell:

function Fix-NetlogonDependency {
    param(
        [string]$Computer = $env:COMPUTERNAME
    )
    Invoke-Command -ComputerName $Computer -ScriptBlock {
        $wkSvc = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation'
        $deps  = (Get-ItemProperty $wkSvc).DependOnService
        if ($deps -contains 'mrxsmb10') {
            Write-Host "[$env:COMPUTERNAME] Quitando mrxsmb10…"
            Set-ItemProperty -Path $wkSvc -Name DependOnService -Value ($deps | Where-Object {$_ -ne 'mrxsmb10'})
            Restart-Service LanmanWorkstation -ErrorAction SilentlyContinue
            Restart-Service Netlogon -ErrorAction SilentlyContinue
        } else {
            Write-Host "[$env:COMPUTERNAME] Dependencia ya corregida"
        }
    }
}

Invoca Fix-NetlogonDependency -Computer PC001 o distribúyelo a un array de equipos para corregir en masa.

Validaciones posteriores

  • Ejecutar gpupdate /force y comprobar la ausencia de errores 1058 / 1030 en el Visor de eventos.
  • Verificar que el recurso \\NombreServidor\SYSVOL es accesible.
  • Comprobar las estadísticas SMB: Get-SmbSession | Group State.
  • Si se habilitó temporalmente SMB v1, monitorizar con Get-SmbServerConfiguration | Select EnableSMB1Protocol hasta su desactivación final.

Buenas prácticas para prevenir recurrencias

  1. Inventario actualizado: conserve un listado de controladores y servicios instalados en cada versión de Windows, incluyendo su origen (imagen base, actualización, driver de terceros).
  2. Política de parcheo estricta: aplique el Patch Tuesday mensual dentro de los 15 días siguientes; la corrección de dependencias viene incluida en paquetes acumulativos recientes.
  3. Directivas de grupo controladas: evite GPO heredadas con scripts que manipulen el registro de servicios sin documentar.
  4. Auditoría continua: habilite la categoría Logon/Logoff y System Events para capturar fallos de Netlogon en tiempo real.
  5. Segmentación de red: limite los puertos 445/139 a los segmentos que necesiten SMB.
  6. Hardening de controladores: bloquee la carga de drivers obsoletos mediante Device Guard o AppLocker.

Preguntas frecuentes

¿Puedo borrar mrxsmb10.sys del sistema?
Sí, pero es innecesario: basta con asegurarse de que su tipo de inicio está en DISABLED. El archivo se conserva para compatibilidad sin ejecutarse.

¿Qué sistemas aún requieren SMB v1?
Equipos con Windows XP, Server 2003, impresoras antiguas y algunos NAS muy desfasados. La recomendación oficial es migrar o actualizar esos dispositivos.

¿Se puede aplicar el cambio mediante GPO?
Sí. Usa Preferences → Registry para modificar la clave HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\DependOnService quitando mrxsmb10.

¿Qué impacto tiene en máquinas fuera de dominio?
Ninguno: Workstation sigue siendo necesario para conexiones SMB entre pares. Eliminar la dependencia no afecta a equipos en grupo de trabajo.

¿Cómo sé si SMB v1 está siendo usado actualmente?
Activa el contador de rendimiento SMB Server Shares ➜ Files Opened /sec filtrando por versión o habilita el registro detallado de SMB en HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters con la clave EnableSMB1ProtocolAudit.

Conclusión

La ausencia de los servicios Netlogon y Workstation suele atribuirse, en la mayoría de los casos modernos, a una dependencia obsoleta de SMB v1. Mientras la reactivación temporal de mrxsmb10 devuelve la red a la operatividad en minutos, la medida definitiva y segura pasa por actualizar el sistema, eliminar la dependencia del controlador e impulsar el uso exclusivo de SMB v2/v3. Adoptar este procedimiento no solo resuelve el síntoma, sino que fortalece la superficie de seguridad del entorno Windows.

Índice