Actualizar los equipos a Windows 11 24H2 puede traer consigo un efecto colateral inesperado en entornos con Windows Server 2016 Essentials: el Dashboard empieza a mostrar los PCs como Offline y la detección de dispositivos en la pestaña Red deja de funcionar. El síntoma confunde porque las carpetas compartidas y el acceso RDP siguen disponibles, lo que hace difícil asociar el problema con Kerberos hasta que se examinan los registros de seguridad. En este artículo encontrarás el porqué y, sobre todo, la forma más eficaz de solucionarlo de manera permanente sin tener que renunciar a la nueva versión de Windows 11.

Resumen del problema

En entornos que usan Windows Server 2016 Essentials o el Essentials Experience instalado como rol sobre Windows Server 2016 Standard, el conector (WseClient.exe) depende de Kerberos para autenticar y notificar la presencia del equipo cliente. Tras actualizar de Windows 11 23H2 a 24H2, el cliente ya no negocia los algoritmos de cifrado RC4 o AES 128/256 que espera el controlador de dominio de 2016. El resultado es que el servidor invalida el ticket y marca el endpoint como Offline, afectando además a la enumeración de dispositivos en la red.

Causa identificada

Microsoft reforzó los requisitos criptográficos de Kerberos en 24H2 para alinearlos con los valores recomendados en Windows Server 2025 y versiones de Azure AD. Las plantillas de directiva local que llegan con la actualización definen de forma más restrictiva la clave SupportedEncryptionTypes. Si el dominio se creó con Windows Server 2016, continuará sirviendo tickets con cifrado “legacy” (RC4HMACMD5) salvo que se configure lo contrario. Al no coincidir los valores ofertados por el cliente y los aceptados por el KDC (Key Distribution Center), el handshake falla y el conector interpreta la ausencia de respuesta como desconexión.

Diagnóstico en tres minutos

1. Abre el Visor de eventos en el cliente y navega a Registro de Windows → Seguridad. Filtra por el ID 4771. Verás errores KRBAPERRMODIFIED y KRBERR_BADOPTION.
2. En el controlador de dominio, abre cmd como administrador y ejecuta klist -li 0x3e7. El SPN del equipo mostrará no se puede encontrar el ticket de concesión.
3. Ejecuta en el cliente reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters". Si SupportedEncryptionTypes aparece con 0x3 o 0x7, confirmarás que solo oferta CF en vez de la gama completa.

Solución definitiva

La forma más robusta de restaurar la compatibilidad es forzar, mediante GPO, que los clientes ofrezcan los mismos algoritmos que el KDC de 2016 puede aceptar. Así se evita también tocar manualmente el Registro en cada PC.

Paso	Acción	Detalle
1	Crear o corregir la GPO de Kerberos	Ruta: Configuración del equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad. Política: Network security: Configure encryption types allowed for Kerberos. Habilitar: RC4HMACMD5, AES128HMACSHA1, AES256HMACSHA1 y Future encryption types.
2	Verificar el Registro en los clientes	Clave: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. Valor SupportedEncryptionTypes = 0x7FFFFFFC (habilita todos los tipos modernos). Si existe con valores 0x1, 0x2 o 0x3, editarlo o esperar a que la GPO lo sobrescriba.
3	Re‑unir los equipos al dominio	– Desinstalar el conector de Essentials. – Pasar el PC a Workgroup. – Instalar o actualizar a 24H2. – Ejecutar de nuevo http://nombre‑del‑servidor/connect y completar el asistente. – Al finalizar, lanzar gpupdate /force y reiniciar.

Una vez desplegada la GPO, los clientes vuelven a mostrarse Online en el Dashboard y la exploración de red se restablece sin necesidad de mantenimiento adicional.

¿Por qué no basta con RC4?

Aunque RC4 sigue habilitado en el AD 2016 para compatibilidad con versiones muy antiguas de Windows, Microsoft lo cataloga como deprecated. Windows 11 24H2, al ver que el KDC ofrece AES 256, prefiere evitar RC4 si  SupportedEncryptionTypes se ajusta a su nueva plantilla. El conflicto surge porque el AD 2016 no anuncia AES 256 de serie, provocando que el cliente ofrezca “nada coincidente”. Permitir ambos algoritmos en la GPO resuelve la discrepancia sin debilitar la seguridad: si AES 256 está disponible, se utilizará en primer lugar.

Medidas alternativas / paliativas

• Rollback a 23H2 y bloqueo de 24H2 usando políticas de Windows Update. Útil solo como solución de urgencia; la compatibilidad a largo plazo quedaría comprometida.
• Network Reset o asignar IP estáticas. Puede suavizar problemas SMB pero no afecta al mecanismo de Kerberos.
• Habilitar insecure guest logons. Desaconsejado: expone el entorno a ataques de pass‑the‑hash y no corrige la raíz del problema.
• Actualizar drivers o reinstalar el conector sin GPO. El síntoma volverá tras el siguiente reinicio porque la política local se regenerará con valores por defecto.

Buenas prácticas y recomendaciones a largo plazo

1. Prueba piloto. Aplica la GPO primero a un equipo de prueba; monitoriza los eventos 4768 (TGT) y 4769 (TGS) para confirmar el uso de AES.
2. Auditoría regular. Programa una tarea que ejecute klist cada 24 horas y vuelque el resultado a un archivo de log centralizado. Ayuda a detectar si algún equipo vuelve a RC4.
3. Revisa los boletines de Microsoft. Cuando aparezca un parche que actualice los valores de cifrado en AD 2016, podrás simplificar la GPO o incluso retirarla.
4. Plan de actualización del dominio. Considera migrar a Windows Server 2025, donde AES 256 es nativo y se ofrece soporte oficial para clientes Windows 11.
5. Documentación interna. Incluye capturas de la GPO, la clave de Registro y los IDs de evento relacionados; agilizará la resolución cuando se incorporen nuevos administradores.

Preguntas frecuentes

¿Puedo deshabilitar Kerberos y usar solo NTLM?

Teóricamente sí, pero es una mala práctica. NTLM v2 es menos seguro y muchas funciones del conector, como la copia de seguridad del PC en la nube, dependen de Kerberos.

¿Sirve lo mismo en Windows Server 2012 R2 Essentials?

Sí, aunque deberás exportar la GPO y vincularla manualmente al dominio 2012. El panel de Essentials 2012 usa el mismo conector y se ve afectado de la misma forma.

¿Cómo verifico que la GPO se aplicó correctamente?

Ejecuta gpresult /R /Scope Computer en el cliente y busca la sección Network security: Configure encryption types allowed for Kerberos. Debe aparecer como Habilitado y con los cuatro tipos marcados.

Guía paso a paso para crear la GPO

1. En el controlador de dominio, abre Group Policy Management.
2. Haz clic derecho en Group Policy Objects y selecciona New. Nómbrala Kerberos Encryption Win11 24H2.
3. Edita la GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options.
4. Localiza Network security: Configure encryption types allowed for Kerberos, define Enabled y marca las casillas: RC4HMACMD5, AES128HMACSHA1, AES256HMACSHA1, Future encryption types.
5. Vincula la GPO a la OU que contiene los equipos Windows 11 o al dominio completo si todos los PCs ya están en 24H2.
6. En un cliente, fuerza la actualización con gpupdate /target:computer /force. Reinicia.
7. Comprueba con klist que el ticket para HOST/servidor muestra Encryption type: AES-256-CTS-HMAC-SHA1-96.

Scripts de automatización (opcional)

# Establece SupportedEncryptionTypes en 0x7FFFFFFC
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" `
  -Name "SupportedEncryptionTypes" -Type DWord -Value 0x7FFFFFFC -Force

Reinicia el servicio KDC local sin reiniciar el equipo

Restart-Service -Name kdc -Force 

Conclusión

El salto a Windows 11 24H2 no tiene por qué romper la integración con Windows Server 2016 Essentials. Con una simple GPO que habilite los algoritmos de cifrado adecuados para Kerberos, los clientes reaparecerán como Online y todas las funcionalidades del Dashboard volverán a la normalidad. Aprovecha la oportunidad para reforzar la seguridad adoptando AES 256 y planifica la actualización de tu dominio para mantenerte dentro del ciclo de soporte oficial.