Autopilot Device Preparation se convierte en estándar, Hybrid Join se queda atrás
Desde septiembre, Microsoft recomienda Autopilot Device Preparation como método estándar para los despliegues de Windows controlados por el usuario. El nuevo procedimiento es más sencillo y estable, pero solo admite Entra Join. Para quienes aún incorporan nuevos dispositivos mediante Hybrid Join, esta es la verdadera noticia: pasar a Entra Join más adelante solo será posible con un reset. Explicamos qué cambia respecto al Autopilot clásico y por qué, de momento, seguimos recomendando el método clásico para los nuevos dispositivos, aunque siempre con Entra Join.

En septiembre, Microsoft declaró Autopilot Device Preparation como el método recomendado para los despliegues de Windows controlados por el usuario. El nuevo modelo es más sencillo y fiable, pero solo admite Entra Join. Quienes aún incorporan dispositivos nuevos mediante Hybrid Join deberían prestar atención precisamente aquí, porque esta limitación tiene más peso que la elección de la herramienta de provisioning adecuada.
Lo más importante en resumen
- Nueva recomendación: Microsoft recomienda Autopilot Device Preparation desde septiembre para los enrollments controlados por el usuario, ya que los despliegues son más rápidos y fiables con este método.
- Solo Entra Join: Device Preparation admite exclusivamente Entra Join; Hybrid Join no está contemplado en el nuevo modelo.
- Sin migración in-place: Microsoft no ofrece un método soportado para convertir un dispositivo con Hybrid Join a Entra Join sin un reset. Quien hoy despliega nuevos dispositivos con Hybrid Join tendrá que provisionarlos de nuevo más adelante o seguirá dependiendo de la infraestructura on-premises durante otro ciclo de hardware completo.
- Sin fecha de desactivación: El Autopilot clásico y Device Preparation coexistirán durante un tiempo previsible.
- Nuestra recomendación: Lo decisivo es el tipo de join, no la herramienta. Para los dispositivos nuevos seguimos usando el Autopilot clásico con Entra Join, porque así los fabricantes y distribuidores pueden registrar los dispositivos antes de la entrega. Device Preparation aún no ofrece este flujo Zero-Touch.
| Windows Autopilot | Autopilot Device Preparation | |
|---|---|---|
| Tipo de join | Entra Join, Hybrid Join | Entra Join |
| Modos | User-driven, Pre-Provisioning, Self-Deploying, dispositivos existentes | User-driven, Automatic (Windows 365) |
| Vinculación al tenant | obligatoria mediante el hardware hash, también a través de OEM y partners | opcional mediante Device Association, de forma manual en Intune |
| Configuración durante el despliegue | por dispositivo y por usuario mediante la Enrollment Status Page (ESP) | solo por dispositivo, con un número limitado de apps y scripts |
| Reporting | con retraso | casi en tiempo real |
| Funciones adicionales | Autopilot Reset, DFCI, Teams Rooms, HoloLens, Self-Deploying, Pre-Provisioning | apps Win32 y LOB en el mismo flujo de despliegue |
Fuente: Microsoft Learn, Compare Windows Autopilot device preparation and Windows Autopilot
Qué ha anunciado Microsoft
A mediados de septiembre, Microsoft describió en el Intune Customer Success Blog cómo debe ser la transición del Windows Autopilot clásico a Device Preparation. El mensaje es claro: para los despliegues controlados por el usuario, Device Preparation es ahora el camino recomendado.
La tecnología en sí no es nueva: Device Preparation existe desde 2024 como una variante de Autopilot completamente rediseñada, más sencilla y fiable, que muestra los despliegues casi en tiempo real. Hasta hace poco, sin embargo, tenía una laguna: antes del primer inicio de sesión, el dispositivo no sabía a qué tenant pertenecía. Esa laguna la cubre la Device Association desde finales de agosto. Con ella podéis asignar un dispositivo Windows a vuestro tenant antes del despliegue; el dispositivo se reconoce automáticamente como equipo corporativo, recibe un nombre predefinido y una experiencia Out-of-Box personalizada, todo antes de que el usuario complete la configuración.
No es necesario migrar de inmediato. El Autopilot clásico y Device Preparation coexisten en el mismo tenant, aunque cada dispositivo utiliza solo uno de los dos modelos. Si un dispositivo está registrado tanto en Autopilot como asignado mediante Device Association, la asociación tiene prioridad.
Una política en lugar de cuatro componentes
El Autopilot clásico se compone de perfiles de despliegue, Enrollment Status Page, Group Tags y grupos dinámicos. Device Preparation funciona con una única política de provisioning que define qué ocurre durante la Out-of-Box Experience (OOBE), desde la configuración del dispositivo hasta las apps, los scripts y el nombre del equipo. En la práctica, esto significa:
- Asignaciones más rápidas: Durante el enrollment, los dispositivos se incorporan inmediatamente a un grupo estático de Entra mediante Enrollment Time Grouping. Las apps y los scripts asignados a ese grupo están disponibles al instante durante el provisioning, sin esperar a que se evalúen los grupos dinámicos.
- Separación clara de fases: Durante el provisioning solo llegan al dispositivo la configuración relacionada con el equipo y las apps estrictamente necesarias. Todo lo relativo al usuario se aplica en cuanto el escritorio está disponible, lo que hace que la configuración inicial sea más corta y menos propensa a errores.
- Mejor reporting: Cada despliegue es visible casi en tiempo real, con muchos más detalles que en el Autopilot clásico, lo que simplifica notablemente la resolución de problemas.
Device Preparation solo admite Entra Join
Device Preparation únicamente admite Entra Join. Hybrid Join no está contemplado en la nueva arquitectura, y nada en los anuncios de Microsoft indica que esto vaya a cambiar. El Autopilot clásico sigue siendo compatible con Hybrid Join, pero el desarrollo de Microsoft apunta claramente hacia despliegues sin Domain Controller. En Microsoft Learn ya se recoge de forma explícita:
„Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended …"
Quien haya utilizado Hybrid Join con Autopilot conoce bien los obstáculos: durante el provisioning el dispositivo debe poder contactar con un Domain Controller, el Intune Connector for Active Directory tiene que estar disponible y funcionar, y las directivas de grupo corren en paralelo a Intune. Precisamente estas dependencias son las que provocan la mayoría de los fallos y bloqueos en los despliegues. Por eso, para nosotros Hybrid Join siempre ha sido una solución de transición, nunca el objetivo final.
Un dispositivo con Entra Join solo necesita una conexión a internet durante la configuración. La configuración, las apps, las actualizaciones y las políticas de cumplimiento llegan íntegramente a través de Intune, y el acceso a los recursos corporativos lo gestiona Conditional Access. Esto encaja con una forma de trabajar que se desarrolla cada vez más fuera de la red corporativa, ya sea en casa, en movilidad o en cualquier punto intermedio.
En nuestra empresa llamamos a este principio "Starbucks Deployment" desde hace años, y ya en 2019 fuimos reconocidos por ello con el Microsoft Global Modern Desktop Partner of the Year Award.
El camino de Hybrid a Entra Join pasa por un reset
Para la planificación hay un punto clave: la única forma soportada de convertir un dispositivo con Hybrid Join en uno con Entra Join es mediante un reset. Cada dispositivo que hoy despleguéis con Hybrid Join tendrá que volver a provisionarse cuando hagáis la transición a Entra Join.
A primera vista puede parecer mucho trabajo, pero en la práctica es perfectamente planificable. Lo más habitual es aprovechar el ciclo de renovación de hardware: los dispositivos nuevos llegan directamente con Entra Join, mientras los que tienen Hybrid Join van saliendo de servicio de forma gradual. Quienes quieran acelerar la migración a la nube pueden reimplantar los dispositivos existentes en oleadas con Entra Join.
Por qué seguimos recomendando Autopilot clásico
Aun así, por el momento no recomendamos migrar a Device Preparation. Para los dispositivos nuevos seguimos apostando por el Autopilot clásico, pero siempre con Entra Join.
La razón principal es la integración con fabricantes y distribuidores. Con el Autopilot clásico, el OEM o el reseller registra el dispositivo directamente en vuestro tenant antes del envío. El dispositivo va directamente a los empleados, muestra vuestro branding desde el primer arranque y se configura solo, sin necesidad de intervención del equipo de IT.
Para la Device Association, en cambio, actualmente tenéis que leer la información del dispositivo de forma local y subirla manualmente a Intune. Esto funciona bien para staging en almacén, despliegues con técnicos o implantaciones internas, pero no para el envío directo a los usuarios. Microsoft ha anunciado que los OEM y partners podrán asignar dispositivos de forma anticipada, aunque sin concretar fechas.
A esto se suman escenarios que Device Preparation aún no cubre del todo:
- Pre-Provisioning: Un partner instala apps y aplica políticas antes de la entrega, de modo que los empleados reciben un dispositivo ya prácticamente configurado.
- Self-Deploying Mode: Dispositivos de quiosco y compartidos que se despliegan sin inicio de sesión de usuario.
- Opciones de provisioning avanzadas: Más apps durante la configuración y la posibilidad de bloquear el escritorio hasta que se complete la configuración relacionada con el usuario.
- Escenarios de dispositivos especiales: Teams Rooms y gestión de firmware mediante DFCI.
En cuanto los fabricantes y distribuidores puedan asignar dispositivos de forma anticipada para Device Preparation, revisaremos nuestra recomendación. La estrategia de fondo no cambia: quien hoy planifica un nuevo despliegue, lo planifica con Entra Join. Una migración posterior del Autopilot clásico a Device Preparation afectará únicamente al flujo de provisioning para nuevos dispositivos, no al modelo de gestión, la plataforma de identidad ni la arquitectura de dispositivos.
«Sin Domain Join nuestros dispositivos no funcionan»
Esta frase la escuchamos constantemente. La tecnología detrás de Entra Join es madura y contrastada, y cuando algo falla, rara vez es culpa de Entra Join en sí, sino de dependencias, procesos y suposiciones que llevan años acumulándose alrededor de Active Directory.
- Directivas de grupo: Muchas organizaciones tienen muchas más GPO de las que necesitan y, según nuestra experiencia, una parte considerable ya no tiene ningún efecto. Con nuestro blueprint, los clientes de Entra arrancan en pocos minutos sobre una baseline probada y flexible que gestionamos íntegramente como Infrastructure as Code en Managed Intune y mantenemos actualizada de forma continua.
- Acceso a recursos on-premises: Los servidores de archivos, las impresoras y las aplicaciones web internas siguen siendo accesibles para los dispositivos con Entra Join. Mientras el dispositivo pueda contactar con un Domain Controller, obtiene tickets Kerberos y se autentica con Single Sign-On en los recursos on-premises, utilizando Windows Hello for Business con Cloud Kerberos Trust. Aun así, debéis probar siempre estos escenarios con usuarios reales y aplicaciones de negocio reales.
- Certificados y acceso a la red: La autenticación en redes y VPN suele depender de certificados de equipo emitidos por una CA on-premises y validados por un Network Policy Server (NPS). En los dispositivos con Entra Join, Intune distribuye los certificados, por ejemplo mediante Microsoft Cloud PKI o SCEPman, y la autenticación en la red la gestiona una solución RADIUS preparada para la nube como RADIUSaaS.
- Despliegues de apps fiables: Cuando los despliegues de Autopilot fallan, la causa suele ser paquetes de software mal construidos o mal mantenidos, no el tipo de join. Por eso utilizamos RealmJoin, nuestro complemento para Intune con más de 2.500 aplicaciones ya empaquetadas. Independientemente de la herramienta, la norma es clara: durante la configuración inicial solo deben instalarse las apps que los usuarios necesitan el primer día. Todo lo demás llega después, una vez que el dispositivo está en producción, o está disponible para autoinstalación en el Intune Company Portal o en el RealmJoin App Catalog.
Conclusión
Device Preparation aún no puede hacer todo lo que hace el Autopilot clásico. Aun así, la dirección es clara: Microsoft invierte en Entra Join, y Hybrid Join se convierte progresivamente en un modelo legacy.
Seguir operando los dispositivos con Hybrid Join existentes hasta el final de su ciclo de vida puede tener sentido, aunque implique mantener en paralelo un modelo de gestión moderno y uno clásico. En cambio, desplegar dispositivos nuevos hoy con Hybrid Join os ata durante otro ciclo de hardware completo a las dependencias on-premises, mientras Microsoft sigue desarrollando el provisioning y la gestión para Entra Join.
Si estáis planificando la migración de Hybrid Join a Entra Join, tenéis problemas con vuestros despliegues de Autopilot o queréis gestionar vuestros dispositivos Windows completamente a través de Intune, estaremos encantados de ayudaros.
Fuentes
- Moving from Windows Autopilot to Windows Autopilot device preparation (Microsoft Tech Community, septiembre de 2026)
- Introducing device association for Windows Autopilot device preparation (Microsoft Tech Community, agosto de 2026)
- Compare Windows Autopilot device preparation and Windows Autopilot (Microsoft Learn)
- Windows Autopilot device association FAQ (Microsoft Learn)
- Microsoft Entra joined vs. hybrid joined (Microsoft Learn)
Contactad con nosotros
¿Estáis planeando migrar de Hybrid Join a Entra Join, vuestros despliegues de Autopilot fallan con más frecuencia de la deseable, o queréis gestionar vuestros dispositivos Windows completamente a través de Intune? Hablad con nosotros y analizamos juntos vuestro entorno.














