Problema

En entornos donde los equipos Windows 11 están Hybrid Azure AD Joined y la política de GPO obliga a la inscripción automática en Intune, es habitual que el proceso se inicie mediante la tarea programada EnterpriseMgmt. Cuando esa tarea nunca se crea, el dispositivo nunca contacta al servicio MDM y queda fuera de la gestión. El síntoma típico es la ausencia de la carpeta Microsoft\Windows\EnterpriseMgmt en el Programador de tareas y la falta de cualquier registro de EnterpriseMgmt al ejecutar schtasks /query. El equipo muestra, sin embargo, un estado de unión correcto (AzureAdJoined = YES, DomainJoined = YES) y los valores de registro de la política de auto‑enrollment están presentes. Este patrón ocurre en varios clientes: la unión híbrida funciona, pero la inscripción MDM no arranca.

Causa

Varios factores pueden impedir que el DeviceEnroller cree la tarea EnterpriseMgmt:

  1. Estado de inscripción previo corrupto
    Si el dispositivo intentó inscribirse antes y falló, quedan restos en el registro (HKLM\Software\Microsoft\Enrollments) o en la base de datos local de MDM. El motor de inscripción lo interpreta como “ya intentado” y no vuelve a lanzar la tarea.

  2. Política de GPO no aplicada al contexto correcto
    La política Enable automatic MDM enrollment using default Azure AD credentials (AutoEnrollMDM=1, UseAADCredentialType=1) debe aplicarse a la Computer Configuration. Cuando la política se define sólo en User Configuration, el agente de inscripción no la ve al arrancar el equipo, por lo que no genera la tarea.

  3. Licencia o alcance de usuario incompleto
    Un usuario con licencia Intune pero con MDM user scope configurado como None o asignado a otro grupo impide que el agente cree la tarea, aunque la política local esté presente.

  4. Problemas de conectividad del agente de inscripción
    El agente usa WinHTTP para contactar los endpoints de MDM. Si la configuración de proxy o de red impide la resolución de *.manage.microsoft.com, el agente aborta antes de crear la tarea. En algunos casos, la ausencia de un certificado de confianza para los endpoints de Intune también bloquea el proceso.

  5. Versión de cliente de Azure AD Connect
    Cuando el conector está desactualizado, la sincronización de atributos críticos (deviceId, deviceTrustType) puede quedar incompleta, provocando que el dispositivo sea reconocido como “Hybrid Joined” pero no como elegible para MDM.

  6. Configuración de “Device Registration Service” deshabilitada
    El servicio dmwappushservice (Device Registration Service) debe estar en ejecución. Si está detenido o configurado para iniciar manualmente, el disparador que crea la tarea nunca se activa.

Solución

Una estrategia genérica, aplicable a la mayoría de los entornos, combina limpieza del estado de inscripción, verificación de políticas y revalidación de conectividad. Los pasos a seguir son:

1. Resetear el estado de inscripción local

  1. Detener el servicio de registro de dispositivos: 
    net stop dmwappushservice
  2. Eliminar las claves de registro que almacenan intentos fallidos: 
    reg delete "HKLM\Software\Microsoft\Enrollments" /f
reg delete "HKLM\Software\Microsoft\Provisioning\OMADM\Accounts" /f
  3. Borrar la carpeta de datos de MDM (si existe): 
    rmdir /s /q "%ProgramData%\Microsoft\IntuneManagementExtension"
  4. Reiniciar el servicio: 
    net start dmwappushservice

2. Confirmar que la política de auto‑enrollment está en Computer Configuration

Revisar la GPO con gpresult /h gpresult.html y buscar los valores:

  • AutoEnrollMDM = 1
  • UseAADCredentialType = 1

Si aparecen bajo User Configuration, mover la configuración a Computer Configuration y forzar la actualización:

gpupdate /force

3. Verificar licencia y alcance de MDM

En el portal de Intune, comprobar que:

  • El usuario tiene asignada una licencia Intune o Microsoft 365 E5.
  • En Devices > Enrollment restrictions > Device enrollment el MDM user scope incluye al usuario (All or a specific group).

4. Probar conectividad a los endpoints de MDM

Ejecutar los siguientes comandos para validar que WinHTTP puede alcanzar los servicios:

winhttpcertcfg -g -c LOCAL_MACHINE\My -s "Microsoft Intune"
curl -I https://enrollment.manage.microsoft.com/EnrollmentServer/Discovery.svc

Si la respuesta es 200, la conectividad está bien. En caso de error, revisar proxy, DNS y certificados raíz.

5. Asegurar que Azure AD Connect está actualizado

Descargar la última versión de Azure AD Connect y ejecutar la actualización. Después, validar que los atributos deviceId y deviceTrustType aparecen en Azure AD con:

Get-AzureADDevice -SearchString "<nombre_del_equipo>"

6. Forzar la creación de la tarea EnterpriseMgmt

Una vez limpiado el estado y confirmada la política, iniciar manualmente el proceso de inscripción:

dsregcmd /join

El agente debería crear la tarea EnterpriseMgmt bajo Microsoft\Windows\EnterpriseMgmt. Si no aparece, lanzar el enrolamiento explícito:

powershell -Command "Start-Process 'C:\Windows\System32\DeviceEnroller.exe' -ArgumentList '/c' -NoNewWindow"

7. Reiniciar el equipo

Un reinicio final garantiza que los servicios de inscripción se inicien con el nuevo estado.

Cuándo aplicar esta solución

  • Síntomas: dispositivo Hybrid Azure AD Joined, política de auto‑enrollment visible, pero sin tarea EnterpriseMgmt y sin inscripción en Intune.
  • Entorno: Windows 11 (Enterprise o Education), Azure AD Connect activo, GPO de MDM habilitada.
  • Exclusiones: equipos que nunca fueron híbridos (solo Azure AD Joined) o que usan inscripción basada en usuario sin GPO (por ejemplo, BYOD con Azure AD Join). En esos casos, la tarea EnterpriseMgmt no es el mecanismo de enrolamiento.

Código

# 1. Detener servicio de registro
net stop dmwappushservice

# 2. Limpiar claves de registro de enrolamiento fallido
reg delete "HKLM\Software\Microsoft\Enrollments" /f
reg delete "HKLM\Software\Microsoft\Provisioning\OMADM\Accounts" /f

# 3. Eliminar datos locales de Intune (opcional)
rmdir /s /q "%ProgramData%\Microsoft\IntuneManagementExtension"

# 4. Reiniciar servicio
net start dmwappushservice

# 5. Forzar unión híbrida y crear tarea
dsregcmd /join
powershell -Command "Start-Process 'C:\Windows\System32\DeviceEnroller.exe' -ArgumentList '/c' -NoNewWindow"

Verificación

  1. Ejecutar schtasks /query /fo LIST /v | findstr /i EnterpriseMgmt.
    Debería aparecer una entrada bajo Microsoft\Windows\EnterpriseMgmt.

  2. Revisar el registro de eventos de DeviceManagement-Enterprise-Diagnostics-Provider (ID 3000‑3010) para confirmar que la inscripción se completó sin errores.

  3. En el portal de Intune, buscar el dispositivo bajo Devices > All devices. El estado debe ser Managed y la columna Enrollment type mostrar Hybrid Azure AD Joined.

  4. Verificar que la política de configuración aplicada aparece en el cliente (gpresult /r → MDM Enrollment = Enabled).

Notas adicionales

  • En entornos con proxy automático (WPAD), la variable WinHTTP a veces no hereda la configuración del navegador. Configurar explícitamente con netsh winhttp set proxy proxy.example.com:8080 puede resolver fallos de conectividad.
  • Si el dispositivo pertenece a varios dominios (forest trusts), asegúrese de que el Primary DNS suffix coincida con el dominio que tiene la política de MDM; de lo contrario, la detección de la política puede fallar.
  • Cuando se trabaja con máquinas virtuales en Azure, habilitar la extensión Azure AD Connect Health ayuda a detectar discrepancias de atributos que provocan este tipo de problemas.