IT Lab Cert
Inicio Cursos Sobre nosotros
English Iniciar sesion Crear cuenta
Puesto de Trabajo Digital

MD-102 Endpoint Administrator (Preparacion de certificacion)

Avanzado 16 modulos • 40 horas

Curso de preparacion para el examen oficial de Microsoft MD-102: Endpoint Administrator. Cubre de forma integra los cinco dominios medidos por el examen en su version del 24 de julio de 2026, con foco en la gestion de dispositivos y aplicaciones en un tenant de Microsoft 365 mediante Microsoft Intune, Intune Suite, Windows Autopilot, Microsoft Defender for Endpoint, Microsoft Entra ID, PowerShell, Microsoft Graph y Windows 365. Es la ruta recomendada para consolidar el rol de administrador de endpoint y para acreditar la competencia de "gestion de endpoint" y "gestion de dispositivos" que exige el puesto de Analista TIC de Puesto de Trabajo Digital.

El curso sigue el mapa oficial del examen y sus pesos: preparar la infraestructura de dispositivos (20-25%), gestionar y mantener dispositivos (25-30%), proteger dispositivos (15-20%), gestionar y asegurar aplicaciones (15-20%) y optimizar operaciones con automatizacion, monitorizacion y reporting (10-15%, dominio nuevo). Cada modulo combina teoria aplicada, rutas reales del portal de Intune (intune.microsoft.com), errores frecuentes y preguntas de autoevaluacion en el estilo de escenario del examen.

Identidad de dispositivo y Microsoft Entra ID

Objetivo del modulo

Comprender como Microsoft Entra ID establece la identidad de un dispositivo y por que esa identidad es el fundamento de toda la gestion moderna del endpoint. El objetivo es que el administrador sepa distinguir con precision los tres estados de union a Entra ID (Entra registered, Entra joined e Hybrid Entra joined), aplicar el criterio de eleccion correcto en cada escenario de negocio, entender el proceso de registro del dispositivo y su representacion como objeto en el directorio, y construir grupos de dispositivos, tanto asignados como dinamicos, cuyas reglas de pertenencia soporten el direccionamiento de politicas, aplicaciones y perfiles en Intune.

Resultados esperados

  • Diferenciar Entra registered, Entra joined e Hybrid Entra joined por su modelo de identidad, autenticacion y casos de uso.
  • Explicar el proceso de device registration y como se materializa el objeto de dispositivo en Entra ID.
  • Aplicar criterios de eleccion del join type segun propiedad, dependencias on-premises y estrategia cloud-first.
  • Crear grupos de dispositivos asignados y dinamicos con reglas de pertenencia correctas.
  • Redactar reglas de pertenencia dinamica usando atributos como deviceOSType, deviceOwnership, enrollmentProfileName o deviceTrustType.
  • Relacionar el estado de identidad con la evaluacion posterior de acceso condicional y cumplimiento.

Desarrollo teorico

La identidad de un dispositivo en Microsoft Entra ID es el punto de partida de la gestion moderna del endpoint. Antes de aplicar una politica de configuracion, desplegar una aplicacion o exigir cumplimiento en acceso condicional, el dispositivo debe existir como objeto en el directorio y tener un estado de union bien definido. Ese estado determina como se autentica el equipo, que identidades de usuario puede usar, que recursos alcanza sin friccion y que controles de seguridad son aplicables. Confundir los estados de union es una de las causas mas frecuentes de comportamiento inesperado en despliegues reales, porque cada estado activa un flujo distinto de single sign-on, de aplicacion de perfiles y de evaluacion de politicas.

Existen tres estados de union. El primero, Microsoft Entra registered (dispositivo registrado), es el modelo mas ligero. El dispositivo obtiene una identidad en Entra ID pero se inicia sesion en el con una cuenta local, una cuenta Microsoft personal o una cuenta de otra organizacion; la identidad de Entra ID se anade encima. Es el modelo natural para BYOD y para plataformas no Windows como Android e iOS/iPadOS, donde el equipo pertenece al empleado y la empresa solo quiere habilitar acceso condicional y proteccion de aplicaciones sin tomar control completo del sistema operativo. El registro se produce, por ejemplo, cuando el usuario anade su cuenta de trabajo a Outlook movil, cuando se inscribe en Intune desde Company Portal o cuando activa "Permitir que mi organizacion administre mi dispositivo" al agregar una cuenta profesional en Windows.

El segundo estado es Microsoft Entra joined (dispositivo unido). Aqui el dispositivo es cloud-native: su identidad reside exclusivamente en Entra ID y los usuarios inician sesion en Windows con sus credenciales de Entra ID. Es el estado recomendado para equipos corporativos Windows 10/11 en organizaciones que adoptan una estrategia cloud-first y no dependen de Active Directory local para el inicio de sesion. Se consigue durante la experiencia inicial (OOBE) al elegir configuracion para una organizacion, mediante Windows Autopilot, o desde Configuracion > Cuentas > Acceso al trabajo o escuela > Conectar > Unir este dispositivo a Microsoft Entra ID. Un dispositivo Entra joined admite SSO fluido a recursos cloud, Windows Hello for Business, y puede acceder a recursos on-premises si existe una linea de vista a un controlador de dominio y esta configurada la sincronizacion adecuada.

El tercer estado es Hybrid Microsoft Entra joined (union hibrida). El dispositivo esta unido simultaneamente a Active Directory local y registrado en Entra ID. Es el estado indicado para organizaciones que ya tienen una inversion en AD DS, aplican Directiva de grupo (GPO) y necesitan que los equipos sigan autenticandose contra el dominio con Kerberos o NTLM para recursos on-premises, pero quieren aprovechar las capacidades cloud como acceso condicional o cumplimiento. La union hibrida se automatiza mediante Microsoft Entra Connect, que sincroniza los objetos de equipo de AD hacia Entra ID; una vez sincronizado, el propio dispositivo completa el registro contra Entra ID en el arranque o inicio de sesion. Hybrid join no es un objetivo estrategico sino de transicion: Microsoft recomienda avanzar hacia Entra joined puro cuando desaparezcan las dependencias on-premises. No existe la union hibrida para dispositivos no Windows.

El proceso de device registration convierte al dispositivo en un objeto de directorio. Ese objeto guarda atributos clave: el identificador del dispositivo, el sistema operativo y su version, el tipo de union (join type o trust type), la propiedad (corporate o personal), el estado de administracion (managed por MDM o no), el estado de cumplimiento devuelto por Intune, y el usuario o usuarios asociados. Estos atributos se consultan en el centro de administracion de Microsoft Entra en Devices > All devices, y tambien en Intune desde Devices > All devices. La propiedad se puede fijar como corporate de forma automatica en escenarios de inscripcion corporativa, o marcarse manualmente. El estado de union se refleja en la columna Join type. Cuando un dispositivo se inscribe en Intune, la afiliacion MDM tambien queda registrada, de modo que Entra ID sabe que ese objeto esta gestionado y puede devolver su cumplimiento a las politicas de acceso condicional.

La eleccion del join type se guia por tres variables. Primera, la propiedad y la plataforma: los dispositivos personales y no Windows tienden a Entra registered; los corporativos Windows a Entra joined. Segunda, las dependencias on-premises: si el inicio de sesion, la impresion, los recursos de archivos o las aplicaciones legadas exigen autenticacion Kerberos contra AD, Hybrid Entra joined suele ser inevitable de forma temporal; si no existen esas dependencias, Entra joined es superior en simplicidad y seguridad. Tercera, la estrategia de despliegue: Autopilot favorece Entra joined y evita la complejidad de la union hibrida, que arrastra dependencias de red y de sincronizacion. El criterio general del examen MD-102 y de las guias de Microsoft es preferir Entra joined siempre que sea posible, usar Hybrid solo cuando persistan dependencias reales de dominio, y reservar Entra registered para BYOD y no Windows.

Los grupos de dispositivos en Entra ID son el mecanismo con el que se direccionan politicas, perfiles y aplicaciones. Un grupo puede ser de tipo Security y su pertenencia puede ser Assigned (asignada, con miembros elegidos manualmente) o Dynamic Device (dinamica, con miembros calculados por una regla). Los grupos dinamicos de dispositivos se crean en el centro de administracion de Microsoft Entra en Groups > All groups > New group, eligiendo Membership type: Dynamic Device y escribiendo una regla en el Rule builder o en el editor de sintaxis. La sintaxis usa atributos del objeto de dispositivo. Ejemplos habituales: (device.deviceOSType -eq "Windows") para todos los Windows; (device.deviceOwnership -eq "Company") para corporativos; (device.enrollmentProfileName -eq "Autopilot-Ventas") para agrupar dispositivos por su perfil de Autopilot; (device.deviceTrustType -eq "AzureAD") para separar Entra joined de Hybrid (ServerAD) y de Workplace (Workplace, es decir registrados). Se pueden combinar condiciones con -and y -or, por ejemplo (device.deviceOSType -eq "Windows") -and (device.deviceOwnership -eq "Company"). La pertenencia dinamica se recalcula automaticamente cuando cambian los atributos, lo que ahorra administracion manual, pero exige que los atributos esten correctamente poblados: si un dispositivo no tiene enrollmentProfileName porque no vino de Autopilot, no entrara en un grupo que dependa de ese atributo. Comprender estas reglas es esencial porque en Intune casi todo se asigna a grupos, y un grupo mal construido despliega politicas a los equipos equivocados o deja fuera a los que deberia cubrir.

Contenido ampliado

Hay matices que suelen generar incidencias. Primero, la diferencia entre deviceTrustType y join type en la interfaz: en las reglas dinamicas el valor AzureAD corresponde a Entra joined, ServerAD a Hybrid Entra joined y Workplace a Entra registered; esta nomenclatura heredada sobrevive en la sintaxis aunque la interfaz muestre etiquetas nuevas. Segundo, los grupos dinamicos no admiten miembros manuales: si necesitas anadir excepciones puntuales, o usas una regla mas fina o pasas a un grupo asignado. Tercero, un dispositivo no puede estar a la vez Entra joined e Hybrid joined; son estados mutuamente excluyentes, y forzar Hybrid sobre un equipo ya Entra joined provoca duplicados y conflictos de identidad visibles como objetos duplicados en All devices.

En BYOD Windows conviene recordar que agregar una cuenta de trabajo con la opcion de permitir gestion produce Entra registered, no Entra joined; el usuario sigue iniciando sesion en Windows con su cuenta personal. Esto sorprende a quien espera un equipo cloud-native. Para plataformas moviles, el concepto de union no aplica igual: iOS/iPadOS y Android se consideran registrados a efectos de identidad, y su gestion se apoya en la inscripcion MDM y no en un join de sistema operativo.

Otro caso limite es el de los dispositivos compartidos o de primera linea, donde interesa agrupar por enrollmentProfileName o por un atributo extendido para separar el kioskos de los equipos de escritorio. Y respecto a licenciamiento y limites: los grupos dinamicos requieren Microsoft Entra ID P1 en el tenant. Finalmente, la latencia de procesamiento de reglas dinamicas en tenants grandes puede ser de minutos a horas; no es instantanea, por lo que un dispositivo recien inscrito puede tardar en recibir politicas dirigidas a su grupo dinamico, algo que hay que tener en cuenta al diagnosticar por que un equipo "no recibe" una configuracion.

Puntos clave

  • Entra registered anade identidad Entra ID a un dispositivo cuyo inicio de sesion sigue siendo local o personal; ideal para BYOD y no Windows.
  • Entra joined es cloud-native: identidad solo en Entra ID, inicio de sesion con credenciales de Entra ID, recomendado para corporativo Windows sin dependencias de dominio.
  • Hybrid Entra joined une AD local y Entra ID; se justifica solo por dependencias reales de Kerberos/NTLM y es un estado de transicion.
  • Microsoft Entra Connect sincroniza los objetos de equipo para habilitar la union hibrida; Autopilot favorece Entra joined puro.
  • El objeto de dispositivo en Entra ID guarda join type, propiedad, estado MDM y cumplimiento, insumos directos del acceso condicional.
  • Los grupos dinamicos de dispositivos usan atributos como deviceOSType, deviceOwnership, enrollmentProfileName y deviceTrustType (AzureAD, ServerAD, Workplace).
  • Los grupos dinamicos requieren Entra ID P1 y no admiten miembros manuales.

Checklist operativa

  • [ ] Inventariar dependencias on-premises que exijan autenticacion de dominio antes de decidir el join type.
  • [ ] Definir la estrategia por plataforma: Entra joined para Windows corporativo, registered para BYOD y movil.
  • [ ] Configurar Microsoft Entra Connect si se requiere Hybrid Entra joined y validar la sincronizacion de objetos de equipo.
  • [ ] Verificar en Entra > Devices > All devices el Join type y la propiedad de una muestra de dispositivos.
  • [ ] Marcar como corporate los dispositivos de empresa que no lo hayan quedado automaticamente.
  • [ ] Crear los grupos dinamicos base (Windows corporativo, no Windows, por perfil de Autopilot) con reglas validadas.
  • [ ] Comprobar que los atributos usados en las reglas (enrollmentProfileName, deviceOwnership) estan poblados.
  • [ ] Documentar que grupo direcciona cada tipo de politica para evitar solapamientos.
  • [ ] Confirmar la licencia Entra ID P1 necesaria para pertenencia dinamica.

Errores frecuentes

  • Confundir Entra registered con Entra joined al agregar una cuenta de trabajo en Windows y esperar un equipo cloud-native.
  • Forzar Hybrid Entra joined en un dispositivo ya Entra joined, generando objetos duplicados y conflictos de identidad.
  • Escribir reglas dinamicas con deviceTrustType -eq "AzureADJoined" en lugar del valor correcto AzureAD.
  • Intentar anadir miembros manuales a un grupo dinamico o esperar que el recalculo sea instantaneo.
  • Direccionar politicas a un grupo cuya regla depende de un atributo no poblado (por ejemplo enrollmentProfileName en equipos no Autopilot).
  • Mantener Hybrid join como objetivo permanente en lugar de tratarlo como transicion hacia cloud-first.

Practica sugerida

En un tenant de pruebas con Entra ID P1, une un equipo Windows 11 mediante Entra joined desde Configuracion > Cuentas > Acceso al trabajo o escuela y verifica en el centro de administracion de Microsoft Entra, en Devices > All devices, que aparece con Join type "Microsoft Entra joined" y estado de MDM correcto. A continuacion registra un dispositivo movil o un segundo equipo como BYOD para obtener un objeto Entra registered y compara ambos objetos: fijate en las columnas Join type, Owner y Ownership.

Despues crea tres grupos dinamicos de dispositivos en Groups > New group con Membership type Dynamic Device: uno con la regla (device.deviceOSType -eq "Windows") -and (device.deviceOwnership -eq "Company"), otro con (device.deviceTrustType -eq "AzureAD") y un tercero con (device.enrollmentProfileName -eq "NOMBRE-DE-TU-PERFIL"). Espera al procesamiento, revisa la pertenencia calculada y ajusta las reglas hasta que cada dispositivo caiga solo en los grupos previstos. Documenta que politicas dirigirias a cada grupo.

Preguntas de autoevaluacion

  1. Que diferencias de identidad y de inicio de sesion existen entre Entra registered, Entra joined e Hybrid Entra joined?
  2. Que dependencias on-premises justifican elegir Hybrid Entra joined en lugar de Entra joined?
  3. Que atributos del objeto de dispositivo se pueden usar en una regla de pertenencia dinamica y que valores toma deviceTrustType?
  4. Por que un equipo puede no recibir una politica pese a cumplir aparentemente la regla de su grupo dinamico?
  5. Que papel juega Microsoft Entra Connect en la union hibrida y por que Autopilot favorece Entra joined?
  6. En que escenario resulta apropiado Entra registered y por que no aplica el concepto de union en dispositivos moviles?

Cierre

La identidad del dispositivo es la base sobre la que se apoya todo el modelo de gestion moderna: sin un estado de union bien elegido y sin grupos correctamente construidos, ninguna politica, perfil o control de acceso condicional se comporta como se espera. Dominar la distincion entre los tres estados de union, el proceso de registro y la sintaxis de las reglas dinamicas prepara el terreno para la inscripcion en Intune y para las decisiones de cumplimiento y acceso condicional que se abordan en los modulos siguientes del Dominio 1.

Inscripcion de dispositivos en Microsoft Intune

Objetivo del modulo

Dominar el proceso de inscripcion de dispositivos en Microsoft Intune por plataforma, entendiendo tanto los ajustes generales de inscripcion como los metodos especificos de Windows, Apple y Android. El objetivo es que el administrador configure la inscripcion automatica de Windows, los perfiles personales y corporativos de macOS, iOS/iPadOS y Android, las restricciones de inscripcion y de plataforma, y las integraciones con Apple Business Manager (ADE), Samsung Knox y Google Zero Touch, sabiendo ademas diagnosticar los fallos de inscripcion mas comunes.

Resultados esperados

  • Configurar la inscripcion automatica de Windows mediante la afiliacion MDM en Microsoft Entra ID.
  • Distinguir los metodos de inscripcion de macOS, iOS/iPadOS entre personal (Company Portal) y corporativa (ADE).
  • Configurar los cuatro perfiles de Android Enterprise: fully managed, dedicated, corporate-owned work profile y personally-owned work profile.
  • Aplicar restricciones de inscripcion por plataforma, version, propiedad y limite por usuario.
  • Integrar Apple Business Manager, Samsung Knox Mobile Enrollment y Google Zero Touch con Intune.
  • Diagnosticar errores frecuentes de inscripcion y su causa raiz.

Desarrollo teorico

La inscripcion es el acto por el que un dispositivo pasa a estar gestionado por Microsoft Intune, recibiendo identidad de administracion, politicas, aplicaciones y controles de seguridad. Todo el proceso se gobierna desde el centro de administracion de Intune (intune.microsoft.com) en Devices > Enrollment, donde las pestanas se organizan por plataforma: Windows, Apple y Android. Antes de inscribir, hay que garantizar dos prerrequisitos transversales: que la autoridad MDM este establecida en Intune (hoy es el valor por defecto) y que los usuarios tengan licencia de Intune asignada. Sin licencia, la inscripcion falla con un error de asignacion, uno de los fallos mas repetidos en la practica.

En Windows, el metodo corporativo por excelencia es la inscripcion automatica, que vincula la union a Microsoft Entra ID con la inscripcion en Intune en un solo paso. Se configura en el centro de administracion de Microsoft Entra en Devices > Mobility (MDM and MAM) > Microsoft Intune, donde se fija el MDM user scope en All o en un grupo concreto. Con ese ambito activado, cuando un equipo se une a Entra ID (por OOBE, por Autopilot o desde Configuracion > Cuentas > Acceso al trabajo o escuela) queda inscrito en Intune automaticamente. Las URLs de terminos de uso, deteccion y cumplimiento MDM se dejan en sus valores por defecto salvo escenarios avanzados. Ademas del enrollment automatico existen otros caminos en Windows: la inscripcion mediante GPO para equipos Hybrid Entra joined, la inscripcion masiva con un paquete de aprovisionamiento y el BYOD, donde el usuario agrega su cuenta de trabajo. El ambito de usuario MDM y el ambito MAM se controlan de forma independiente, y confundirlos provoca que un equipo no se inscriba pese a estar unido.

Los ajustes generales de inscripcion de Windows se definen en Devices > Enrollment > Windows. Ahi estan la Enrollment Status Page (ESP), que muestra el progreso de aprovisionamiento y puede bloquear el uso del equipo hasta completar apps y politicas criticas; los Deployment Profiles de Autopilot; el Windows Hello for Business a nivel de inscripcion; y las Enrollment restrictions. Aunque Autopilot se estudia en detalle en el Dominio 2, conviene saber que su perfil determina el tipo de union (Entra joined o Hybrid) y la experiencia del usuario.

En Apple, la inscripcion se configura en Devices > Enrollment > Apple. El requisito inicial es cargar un Apple MDM Push certificate (APNs), sin el cual no se puede gestionar ningun dispositivo Apple; caduca cada ano y su renovacion con el mismo Apple ID es critica, porque renovarlo con otro Apple ID obliga a reinscribir todos los dispositivos. Para dispositivos personales macOS, iOS y iPadOS, el usuario instala Company Portal y realiza una inscripcion voluntaria; en iOS/iPadOS moderna se usa la User Enrollment o la Device Enrollment segun el nivel de control deseado, y el dispositivo queda como personal. Para dispositivos corporativos comprados por la empresa, el metodo es Automated Device Enrollment (ADE), antes conocido como DEP, que se apoya en Apple Business Manager (o Apple School Manager). Con ADE, los dispositivos aparecen supervisados y se inscriben durante el Setup Assistant sin que el usuario pueda evitarlo, permitiendo el maximo control. Tambien existe la inscripcion mediante Apple Configurator para escenarios de aprovisionamiento por cable.

Android se gestiona con Android Enterprise, que ofrece cuatro escenarios de inscripcion configurables en Devices > Enrollment > Android. El primero, fully managed (propiedad corporativa, totalmente gestionado), aplica MDM completo sobre todo el dispositivo; es para equipos de empresa asignados a un unico empleado. El segundo, dedicated devices (dedicados, antes COSU), es para dispositivos compartidos o de proposito unico como kioscos, TPVs o terminales de almacen, habitualmente sin cuenta de usuario y en modo quiosco. El tercero, corporate-owned work profile (COPE, propiedad corporativa con perfil de trabajo), combina propiedad de empresa con separacion de un perfil de trabajo y un espacio personal, para dispositivos corporativos que la organizacion permite usar tambien de forma personal. El cuarto, personally-owned work profile (BYOD), crea un contenedor de trabajo aislado en el dispositivo personal del empleado, protegiendo datos corporativos sin tocar el espacio personal. Antes de usar cualquiera de ellos hay que conectar Intune con Managed Google Play en Devices > Enrollment > Android > Managed Google Play, una vinculacion unica que habilita el resto.

Las restricciones de inscripcion son el control de gobierno que decide que puede y que no puede inscribirse. Se configuran en Devices > Enrollment > Enrollment restrictions e incluyen dos tipos. Las Device platform restrictions permiten bloquear o permitir plataformas concretas, exigir una version minima o maxima del sistema operativo, y bloquear la inscripcion de dispositivos personales para forzar que solo se inscriban los corporativos; por ejemplo, se puede permitir iOS pero bloquear su inscripcion como personal, o bloquear Android device administrator (el metodo legado) para forzar Android Enterprise. Las Device limit restrictions fijan cuantos dispositivos puede inscribir cada usuario (por defecto 15, configurable de 1 a 15). Estas restricciones se pueden priorizar y asignar a grupos, de modo que distintos colectivos tengan reglas distintas. Un uso tipico es impedir que los dispositivos personales no confiables entren en la gestion mientras se admite el BYOD solo via MAM.

Las integraciones con fabricantes automatizan el aprovisionamiento a escala. Apple Business Manager (ABM) es el portal donde la empresa vincula sus compras de hardware Apple y las asigna a servidores MDM; su token se sincroniza con Intune para habilitar ADE, de forma que cada dispositivo comprado se inscribe supervisado desde el primer arranque. En Android, Samsung Knox Mobile Enrollment (KME) hace lo equivalente para dispositivos Samsung: los equipos registrados en Knox se inscriben automaticamente en Intune al conectarse a la red durante la configuracion inicial. Google Zero Touch Enrollment es el mecanismo generico de Android para dispositivos de fabricantes compatibles: el revendedor registra los dispositivos, se asocian a una configuracion que apunta a Intune y se inscriben sin intervencion del usuario. Todas estas integraciones comparten un patron: el hardware llega preasignado a la organizacion, y al encenderse se dirige solo al servicio MDM correspondiente, eliminando el aprovisionamiento manual. El troubleshooting de inscripcion parte de identificar en que fase falla: prerrequisitos (licencia de Intune, APNs, ambito MDM), restricciones (plataforma o version bloqueada, limite de dispositivos alcanzado), identidad (el usuario no esta en el grupo del MDM scope) o token caducado (APNs, ADE o VPP). Los codigos de error de inscripcion y los detalles se revisan en Intune en Devices > Enrollment > Enrollment failures y en Company Portal del propio dispositivo.

Contenido ampliado

Varios matices marcan la diferencia entre un despliegue fluido y una avalancha de tickets. El certificado APNs de Apple es un punto unico de fallo silencioso: si caduca, los dispositivos existentes dejan de recibir politicas y no se pueden inscribir nuevos; la renovacion debe hacerse con el mismo Apple ID corporativo, idealmente una cuenta de servicio documentada y no la cuenta personal de un tecnico. Con ADE, el ajuste "Await final configuration" fuerza que el Setup Assistant no termine hasta aplicar la configuracion critica, util para equipos que deben estar conformes antes de llegar al usuario.

En Android conviene evitar el metodo legado Android device administrator, en retirada por Google; las restricciones de plataforma deberian bloquearlo para forzar Android Enterprise. Para dispositivos dedicados con Microsoft Entra shared device mode se logra que aplicaciones como Teams o Managed Home Screen gestionen el inicio y cierre de sesion de varios usuarios de primera linea con limpieza de datos al cerrar. En COPE hay que comunicar bien al usuario que la empresa gestiona el dispositivo entero aunque exista un espacio personal, para evitar expectativas equivocadas de privacidad.

Sobre limites y licenciamiento: cada plataforma tiene su token o certificado con caducidad (APNs anual, token ADE anual, token VPP anual), y un panel de estado de conectores en Tenant administration > Connectors and tokens ayuda a vigilarlos. Un error clasico es el limite de 15 dispositivos por usuario, que en entornos con muchos equipos de prueba se agota y bloquea nuevas inscripciones con un mensaje que no siempre es evidente. Finalmente, las Enrollment restrictions de plataforma no reemplazan al acceso condicional: un dispositivo bloqueado para inscripcion aun podria acceder a recursos via navegador si no hay politicas de CA, algo que hay que cubrir con las capas del modulo de cumplimiento y acceso condicional.

Puntos clave

  • La inscripcion automatica de Windows vincula el join a Entra ID con Intune y se activa fijando el MDM user scope en Entra > Devices > Mobility.
  • Todo dispositivo Apple exige un certificado APNs vigente; renovarlo con otro Apple ID obliga a reinscribir.
  • ADE con Apple Business Manager inscribe dispositivos corporativos supervisados desde el Setup Assistant.
  • Android Enterprise ofrece fully managed, dedicated, corporate-owned work profile y personally-owned work profile, previa vinculacion con Managed Google Play.
  • Las Device platform restrictions filtran por plataforma, version y propiedad; las Device limit restrictions limitan dispositivos por usuario (max 15).
  • Samsung Knox Mobile Enrollment y Google Zero Touch automatizan la inscripcion de Android sin intervencion del usuario.
  • El troubleshooting parte de la fase de fallo: prerrequisitos, restricciones, identidad o tokens caducados.

Checklist operativa

  • [ ] Confirmar que la autoridad MDM es Intune y que los usuarios tienen licencia de Intune.
  • [ ] Fijar el MDM user scope en Entra > Devices > Mobility para habilitar la inscripcion automatica de Windows.
  • [ ] Cargar y anotar la caducidad del certificado APNs con un Apple ID corporativo de servicio.
  • [ ] Vincular Apple Business Manager y sincronizar el token ADE para dispositivos corporativos Apple.
  • [ ] Conectar Managed Google Play y definir los perfiles de inscripcion de Android necesarios.
  • [ ] Configurar Enrollment restrictions de plataforma para bloquear personales o versiones no soportadas segun politica.
  • [ ] Revisar el limite de dispositivos por usuario y ajustarlo si hay muchos equipos por persona.
  • [ ] Integrar Samsung Knox Mobile Enrollment o Google Zero Touch si el parque lo requiere.
  • [ ] Vigilar el estado de tokens y certificados en Tenant administration > Connectors and tokens.
  • [ ] Validar una inscripcion de prueba por plataforma y revisar Enrollment failures.

Errores frecuentes

  • No asignar licencia de Intune al usuario, provocando fallo de inscripcion por asignacion.
  • Dejar el MDM user scope en None o apuntando a un grupo que no incluye al usuario que intenta inscribir.
  • Renovar el certificado APNs con un Apple ID distinto, obligando a reinscribir todo el parque Apple.
  • Olvidar vincular Managed Google Play antes de crear perfiles de Android Enterprise.
  • Alcanzar el limite de 15 dispositivos por usuario y no entender el mensaje de bloqueo resultante.
  • Permitir el metodo legado Android device administrator en lugar de forzar Android Enterprise.

Practica sugerida

En un tenant de pruebas, habilita la inscripcion automatica de Windows configurando el MDM user scope en el centro de administracion de Microsoft Entra (Devices > Mobility > Microsoft Intune) para un grupo piloto, une un equipo Windows 11 a Entra ID y verifica que aparece inscrito en Intune en Devices > Windows. A continuacion, en Intune > Devices > Enrollment > Enrollment restrictions, crea una restriccion de plataforma que bloquee la inscripcion de dispositivos iOS personales y otra que limite a 5 el numero de dispositivos por usuario; asignalas a tu grupo piloto y comprueba el efecto intentando una inscripcion que deba ser bloqueada.

Si dispones de dispositivos Android de prueba, conecta Managed Google Play y crea un perfil de inscripcion de personally-owned work profile y otro de fully managed; inscribe un dispositivo con cada uno y compara la experiencia y la separacion de datos. Revisa por ultimo Devices > Enrollment > Enrollment failures para familiarizarte con los codigos de error y su interpretacion.

Preguntas de autoevaluacion

  1. Que ajuste habilita la inscripcion automatica de Windows y donde se configura exactamente?
  2. Que consecuencia tiene renovar el certificado APNs con un Apple ID diferente al original?
  3. Que diferencia a fully managed, dedicated, corporate-owned work profile y personally-owned work profile en Android Enterprise?
  4. Como se usan las Device platform restrictions para impedir la inscripcion de dispositivos personales?
  5. Que aportan Apple Business Manager (ADE), Samsung Knox Mobile Enrollment y Google Zero Touch frente a la inscripcion manual?
  6. Ante un fallo de inscripcion, que fases revisarias en orden para localizar la causa raiz?

Cierre

La inscripcion es la puerta de entrada a la gestion y su configuracion correcta condiciona la experiencia del usuario y la capacidad de gobierno de la organizacion. Conocer los metodos de cada plataforma, las restricciones de inscripcion y las integraciones con fabricantes permite automatizar el alta a escala y evitar los fallos mas comunes. Con la identidad del dispositivo y la inscripcion resueltas, el siguiente paso del Dominio 1 es delegar la administracion con RBAC y scope tags para operar el entorno de forma segura y ordenada.

Registrate gratis para acceder a los 14 modulos restantes, examenes y certificados.

Crear cuenta gratis

Resultados de aprendizaje

  • Preparar la infraestructura de dispositivos: join a Entra ID, inscripcion en Intune por plataforma, RBAC y scope tags, cumplimiento y acceso condicional.
  • Desplegar y mantener dispositivos con Autopilot y device preparation, perfiles de configuracion, Windows 365, Intune Suite y acciones remotas.
  • Proteger dispositivos con baselines de seguridad, cifrado, ASR, Defender for Endpoint y gestion de actualizaciones (update rings, Autopatch, Hotpatch).
  • Gestionar y asegurar aplicaciones: despliegue de apps Win32/LOB/M365 y politicas de proteccion y configuracion de apps.
  • Optimizar operaciones con PowerShell y Microsoft Graph, agentes de Security Copilot en Intune, Endpoint Analytics y reporting.

Publico objetivo

Administradores de endpoint, tecnicos y analistas de puesto de trabajo digital que gestionan dispositivos Windows y no Windows con Microsoft Intune y quieren certificarse en MD-102. Tambien util para responsables de servicio que necesitan dominar el modelo de gestion moderna del endpoint.

Requisitos previos

- Experiencia con Microsoft Entra ID y tecnologias de Microsoft 365, incluida Intune. - Conocimiento de despliegue, configuracion y mantenimiento de clientes Windows y dispositivos no Windows. - Nociones de Microsoft Defender XDR y conceptos de identidad y acceso. - Recomendado haber cursado antes "Intune y Gestion de Dispositivos", "Windows 10/11 en entorno corporativo" y "Autopilot y Despliegue Zero-Touch".

Guia de estudio

Guia de estudio del examen MD-102: Endpoint Administrator

Esta guia te dice como abordar el examen MD-102 que acredita la certificacion Microsoft Certified: Endpoint Administrator Associate, con un plan de estudio semana a semana apoyado en los 16 modulos del curso y en las habilidades medidas a fecha de 24 de julio de 2026.

Como es el examen

  • Nota de corte: 700 sobre 1000. La escala no es un porcentaje directo de aciertos: Microsoft pondera las preguntas, asi que 700/1000 no equivale exactamente a un 70% de respuestas correctas.
  • Numero de preguntas: en torno a 40-60 items. Microsoft no publica el numero exacto y puede variar entre convocatorias.
  • Duracion: dispones de tiempo suficiente para leer con calma (habitualmente algo mas de 60-100 minutos de trabajo efectivo). Si el examen no esta en tu idioma preferido puedes solicitar 30 minutos adicionales.
  • Formatos de pregunta: opcion multiple de respuesta unica, respuesta multiple (elige N), drag and drop de ordenacion o emparejamiento, listas desplegables para completar frases, hot area sobre una captura, casos de estudio (case studies) con varias preguntas sobre un mismo escenario, y bloques de tipo "Yes/No" donde valoras si cada solucion propuesta cumple el objetivo. Ojo con estos ultimos: cada afirmacion se evalua de forma independiente y no puedes volver atras dentro del bloque.
  • Contenido: la mayoria de preguntas cubren funciones en disponibilidad general (GA); puede aparecer alguna en Preview si es de uso comun (por ejemplo agentes de Security Copilot en Intune).
  • Entorno de practica: usa el exam sandbox (aka.ms/examdemo) para familiarizarte con la interfaz antes del dia.

Mapa de dominios y pesos

Dominio Peso Modulos del curso
D1. Preparar la infraestructura de dispositivos 20-25% 01, 02, 03, 04
D2. Gestionar y mantener dispositivos 25-30% 05, 06, 07, 08, 09
D3. Proteger dispositivos 15-20% 10, 11, 12
D4. Gestionar y asegurar aplicaciones 15-20% 13, 14
D5. Optimizar operaciones (automatizacion, monitorizacion, reporting) 10-15% 15, 16

El D2 es el de mayor peso: si tienes que priorizar, domina Autopilot/device preparation, perfiles de configuracion y acciones remotas. El D5 es nuevo (julio 2026): no lo dejes fuera aunque pese menos, porque introduce PowerShell, Microsoft Graph, Security Copilot y Endpoint Analytics.

Plan de estudio semana a semana

Plan de 6 semanas a un ritmo de estudio compatible con jornada laboral. Comprime a 4 semanas si ya administras Intune a diario.

  • Semana 1 - Fundamentos de infraestructura (D1). Modulos 01 y 02. Interioriza los tipos de union a Entra ID (Entra registered, Entra joined, hybrid joined) y cuando usar cada uno; los grupos dinamicos y sus reglas de pertenencia; la inscripcion por plataforma (enrollment automatico de Windows, ABM para Apple, Android Enterprise, Knox, Zero-Touch). Practica: crea una regla de grupo dinamico y un perfil de restriccion de inscripcion.
  • Semana 2 - Identidad, cumplimiento y RBAC (D1). Modulos 03 y 04. RBAC de Intune, scope tags y administracion delegada (scoped admin), multi-admin approval, compliance policies, Acceso Condicional que exige estado compliant, Windows Hello for Business y Windows LAPS. Practica: crea una compliance policy y una politica de CA "require compliant device".
  • Semana 3 - Despliegue y configuracion (D2). Modulos 05, 06 y 07. Autopilot deployment profiles vs device preparation policies, modos user-driven / pre-provisioning / self-deploying, ESP, Windows 365 Cloud PC, Windows Backup, Settings Catalog, importacion de ADMX, Group Policy analytics, filtros de asignacion y enrollment time grouping. Esta semana concentra muchos puntos: no la aceleres.
  • Semana 4 - Intune Suite, acciones remotas y proteccion (D2 y D3). Modulos 08, 09 y 10. EPM, Enterprise App Catalog, Remote Help, Cloud PKI, Microsoft Tunnel, Advanced Analytics; acciones remotas (sync, wipe, retire, rotacion de claves BitLocker/LAPS, device query con KQL, recogida de diagnosticos); baselines, cifrado, firewall, ASR, App Control for Business.
  • Semana 5 - Defender, actualizaciones y apps (D3 y D4). Modulos 11, 12, 13 y 14. Integracion con Defender for Endpoint y politicas EDR, onboarding; update rings, feature/quality updates, Autopatch y Hotpatch, Delivery Optimization; despliegue de apps Win32/LOB/Store/M365, VPP y Google Play, app protection policies (MAM) y app configuration policies.
  • Semana 6 - Operaciones y repaso (D5 + transversal). Modulos 15 y 16. PowerShell y Microsoft Graph, agentes de Security Copilot en Intune, Endpoint Analytics, proactive remediations, reporting y alertas. Dedica los ultimos dias al Practice Assessment oficial, revisa el glosario y las tablas de decision, y repasa los case studies del caso practico integrador.

Consejos por dominio

  • D1: memoriza la matriz "escenario -> tipo de union" y "escenario -> metodo de inscripcion". Muchas preguntas se resuelven eligiendo el join type o el enrollment correcto.
  • D2: ten muy clara la diferencia device preparation vs deployment profile, los tres modos de Autopilot y para que sirve el ESP. Distingue perfil de configuracion (Settings Catalog) de compliance policy.
  • D3: separa lo que hace un security baseline de una compliance policy y de una endpoint security policy; entiende ASR, cifrado BitLocker con recuperacion self-service, y la cadena update ring -> feature/quality -> Autopatch/Hotpatch.
  • D4: Win32 (.intunewin) vs LOB vs Store; MAM (app protection) vs MDM; VPP para Apple. Recuerda que app protection puede aplicarse a dispositivos no inscritos (BYOD).
  • D5: conceptos de Graph/PowerShell para automatizar, que aportan los agentes de Security Copilot, y la diferencia entre Endpoint Analytics, proactive remediation y reporting/alertas.

Recursos oficiales

  • Study guide oficial: learn.microsoft.com/credentials/certifications/resources/study-guides/md-102.
  • Learning paths y modulos de MD-102 en Microsoft Learn (ruta "Two ways to prepare" de la pagina del examen).
  • Documentacion de Intune, Autopilot, Defender for Endpoint y Windows 365.
  • Practice Assessment gratuito de Microsoft y el Exam Readiness Zone en Microsoft Learn Shows.

Recuerda que la certificacion caduca anualmente y se renueva con una evaluacion gratuita en Microsoft Learn.

Examen disponible

Este curso incluye un examen de 40 preguntas. Registrate gratis para acceder al examen y obtener tu certificado digital.

Crear cuenta gratis

Glosario del examen MD-102

Terminos clave para el examen MD-102. Usa siempre la terminologia actual: Microsoft Entra ID, nunca "Azure AD".

  • Microsoft Entra ID — Servicio de identidad y acceso en la nube de Microsoft (antes Azure AD). Base de la identidad de usuarios y dispositivos gestionados.
  • Entra registered — Dispositivo registrado en Entra ID pero con identidad personal; tipico de BYOD. Da acceso condicional sin unir el equipo al tenant.
  • Entra joined (Entra join) — Dispositivo Windows corporativo unido solo a la nube (sin Active Directory local). Cuenta de trabajo como identidad principal.
  • Hybrid Entra joined — Dispositivo unido a Active Directory local y sincronizado/unido tambien a Entra ID. Escenario de coexistencia con dominio on-premises.
  • Device registration — Proceso por el que un dispositivo obtiene identidad en Entra ID para aplicar politicas y acceso condicional.
  • Grupo asignado — Grupo de Entra cuya pertenencia se gestiona manualmente anadiendo miembros.
  • Grupo dinamico — Grupo cuya pertenencia se calcula automaticamente segun una regla (device o user attributes), por ejemplo por sistema operativo o fabricante.
  • Intune (Microsoft Intune) — Servicio de gestion de endpoints (MDM/MAM) en la nube. Portal en intune.microsoft.com.
  • MDM (Mobile Device Management) — Gestion del dispositivo completo: configuracion, cumplimiento, cifrado, wipe.
  • MAM (Mobile Application Management) — Gestion a nivel de aplicacion (proteccion de datos de la app) sin gestionar todo el dispositivo; clave en BYOD.
  • Enrollment (inscripcion) — Alta de un dispositivo en Intune para que reciba politicas. Puede ser automatica, por usuario o corporativa.
  • Automatic enrollment — Inscripcion automatica en Intune al unir un Windows a Entra ID (requiere licencia y configuracion del alcance MDM).
  • Apple Business Manager (ABM) — Portal de Apple que, integrado con Intune, permite inscripcion corporativa (ADE/DEP) de macOS, iOS y iPadOS.
  • Android Enterprise — Modelo de gestion de Android: fully managed, dedicated, corporate-owned work profile y personally-owned work profile.
  • Knox Mobile Enrollment / Zero-Touch — Metodos de inscripcion corporativa masiva para Android (Samsung Knox y Google Zero-Touch).
  • Enrollment restrictions — Reglas que limitan que plataformas o dispositivos (personales vs corporativos) pueden inscribirse.
  • RBAC (Role-Based Access Control) — Control de acceso por roles en Intune; roles integrados o personalizados con asignaciones.
  • Scope tag — Etiqueta que delimita que objetos ve y gestiona un administrador; base de la administracion delegada (scoped admin).
  • Multi-admin approval (MAA) — Requiere que un segundo administrador apruebe cambios sensibles (por ejemplo apps o scripts) antes de aplicarlos.
  • Compliance policy — Politica que evalua si un dispositivo cumple requisitos (cifrado, version de SO, antivirus...) y marca su estado compliant/non-compliant.
  • Conditional Access (Acceso Condicional) — Politicas de Entra ID que conceden o bloquean acceso segun senales de identidad, dispositivo o riesgo; tipicamente "require compliant device".
  • Windows Hello for Business — Autenticacion sin contrasena basada en PIN o biometria ligada al dispositivo.
  • Windows LAPS — Local Administrator Password Solution: gestiona y rota la contrasena del administrador local, almacenandola en Entra ID o AD.
  • Windows Autopilot — Servicio de aprovisionamiento zero-touch de Windows corporativo desde la nube.
  • Deployment profile (Autopilot) — Perfil clasico de Autopilot que define la experiencia OOBE y el modo de despliegue.
  • Device preparation policy — Modelo mas reciente y simplificado de aprovisionamiento de Windows, alternativa a los deployment profiles clasicos.
  • User-driven / Pre-provisioning / Self-deploying — Los tres modos de despliegue de Autopilot: con usuario, pre-aprovisionado (white glove) y sin usuario (kioscos/quioscos).
  • ESP (Enrollment Status Page) — Pantalla que muestra y bloquea el progreso de configuracion durante la inscripcion hasta que se aplican apps y politicas criticas.
  • Windows 365 / Cloud PC — PC en la nube gestionado con Intune mediante provisioning policies, conexiones de red e imagenes.
  • Windows Backup (para Organizaciones) — Copia y restauracion de la configuracion del usuario/dispositivo Windows gestionada desde Intune.
  • Settings Catalog — Catalogo unificado de miles de opciones de configuracion para crear perfiles granulares por plataforma.
  • ADMX import — Importacion de plantillas administrativas ADMX para configurar aplicaciones no cubiertas por defecto.
  • Group Policy analytics — Herramienta que analiza GPO on-premises y sugiere su equivalencia en Intune.
  • Assignment filter (filtro) — Filtro basado en propiedades del dispositivo que afina a que subconjunto se aplica una asignacion (incluir/excluir).
  • Enrollment time grouping — Asignacion de dispositivos a grupos en el momento de la inscripcion (via Autopilot device preparation).
  • Intune Suite — Complemento de pago con capacidades avanzadas: EPM, Remote Help, Cloud PKI, Microsoft Tunnel, Enterprise App Catalog y Advanced Analytics.
  • EPM (Endpoint Privilege Management) — Permite elevar aplicaciones concretas sin dar derechos de administrador permanentes, con politicas de elevacion y auditoria.
  • Enterprise App Catalog — Catalogo curado de apps empresariales listas para desplegar con Intune.
  • Remote Help — Asistencia remota segura e integrada con Intune y el RBAC del tenant.
  • Cloud PKI — PKI gestionada en la nube por Intune para emitir y renovar certificados automaticamente.
  • Microsoft Tunnel — Puerta VPN para acceso a recursos corporativos, extensible a MAM.
  • Advanced Analytics — Analitica avanzada de Intune: deteccion de anomalias, insights proactivos y recomendaciones basadas en riesgo.
  • Remote actions (acciones remotas) — Sync, restart, retire, wipe, rotacion de claves BitLocker/LAPS, actualizacion de inteligencia de Defender, etc.
  • Retire vs Wipe — Retire elimina datos y gestion corporativos dejando los personales; Wipe restablece el dispositivo a fabrica.
  • Device query (KQL) — Consulta en tiempo real del estado de un dispositivo mediante Kusto Query Language.
  • Security baseline — Conjunto preconfigurado de ajustes de seguridad recomendados por Microsoft aplicables con Intune.
  • ASR (Attack Surface Reduction) — Reglas que reducen la superficie de ataque bloqueando comportamientos de riesgo (macros, scripts...).
  • App Control for Business — Control de aplicaciones permitidas/bloqueadas (sucesor de WDAC) gestionado con Intune.
  • BitLocker / Disk encryption policy — Cifrado de disco con gestion de claves de recuperacion, recuperacion self-service y monitorizacion de cumplimiento.
  • Defender for Endpoint (MDE) — Plataforma EDR/XDR de Microsoft; se integra con Intune para onboarding y politicas EDR.
  • EDR (Endpoint Detection and Response) — Deteccion y respuesta ante amenazas en el endpoint gestionada con MDE.
  • Update ring — Anillo de actualizacion que define diferimientos y ventanas para quality y feature updates de Windows.
  • Feature / Quality update — Actualizaciones de version (feature) y de calidad/seguridad (quality) gestionadas desde Intune.
  • Windows Autopatch — Servicio que automatiza el despliegue de actualizaciones de Windows, Office, Edge y Teams por anillos gestionados.
  • Hotpatch — Actualizaciones de seguridad que se aplican sin reinicio; se configuran mediante politicas de Autopatch/Hotpatch.
  • Delivery Optimization — Optimizacion de ancho de banda que comparte contenido de actualizacion entre equipos.
  • Win32 app (.intunewin) — Aplicacion empaquetada con la Win32 Content Prep Tool para desplegar con Intune.
  • LOB app — Aplicacion de linea de negocio (paquete propio, por ejemplo .msi, .apk, .ipa) subida directamente a Intune.
  • VPP (Volume Purchase Program) — Compra por volumen de Apple, integrada con ABM, para distribuir apps y licencias.
  • App protection policy (APP) — Politica MAM que protege los datos corporativos dentro de la app (cifrado, PIN, bloqueo de copiar/pegar), incluso en BYOD.
  • App configuration policy — Preconfigura ajustes de una app gestionada para dispositivos o apps gestionadas.
  • Quiet Time policy — Politica que silencia notificaciones de apps en horarios definidos (Android/iOS).
  • Microsoft Graph — API unificada para automatizar Intune y otros servicios de Microsoft 365.
  • Security Copilot (agentes en Intune) — Agentes de IA que investigan amenazas, analizan rendimiento y recomiendan decisiones de gestion.
  • Endpoint Analytics — Analitica de experiencia del usuario: startup score, device health, app reliability y proactive remediations.
  • Proactive remediation — Pares de scripts de deteccion y correccion que detectan y arreglan problemas comunes de forma programada.

Laboratorio / Taller

Laboratorio guiado: seis tareas clave de Intune (MD-102)

Laboratorio practico en un tenant de pruebas de Microsoft Intune. Realizalo con una VM Windows 11 y, para la app protection, un movil o emulador Android/iOS. Todas las rutas parten del portal de Intune: intune.microsoft.com (Microsoft Intune admin center). No hagas este lab en un tenant de produccion.

Aviso: los nombres exactos de algunas hojas del portal cambian con el tiempo. Si no encuentras una opcion, usa el buscador superior del portal.

Preparacion

  1. Consigue un trial de Intune (30 dias) o un tenant de desarrollo con licencias que incluyan Intune y Entra ID P1.
  2. Crea un grupo de seguridad de prueba en Groups > New group (por ejemplo LAB-Windows) y anade tu VM/usuario de prueba.
  3. Inscribe la VM Windows 11 en Intune (Entra join + inscripcion automatica) para tener un dispositivo objetivo.

Tarea 1 - Compliance policy (Windows)

  1. Ve a Devices > Compliance > Create policy.
  2. Platform: Windows 10 and later. Pulsa Create.
  3. En Compliance settings activa, por ejemplo, BitLocker: Require, Minimum OS version y Antivirus: Require.
  4. En Actions for noncompliance deja "Mark device noncompliant" (puedes anadir un correo al usuario tras N dias).
  5. En Assignments asigna al grupo LAB-Windows. Review + create.
  6. Verifica en Devices > Compliance que el dispositivo pasa a Compliant tras el siguiente check-in.

Tarea 2 - Perfil de configuracion con Settings Catalog

  1. Ve a Devices > Configuration > Create > New policy.
  2. Platform Windows 10 and later, Profile type Settings catalog. Create.
  3. En Configuration settings pulsa Add settings, busca por ejemplo "Power" o "Screen lock" y anade uno o dos ajustes concretos (por ejemplo tiempo de bloqueo de pantalla).
  4. (Opcional) En Scope tags asigna una etiqueta de alcance.
  5. Assignments: asigna al grupo LAB-Windows. Practica un assignment filter (incluir solo dispositivos cuyo deviceOwnership sea Corporate): crea el filtro en Tenant administration > Filters y aplicalo en la asignacion.
  6. Review + create y comprueba el estado en la pestana Device status del perfil.

Tarea 3 - Update ring de Windows

  1. Ve a Devices > Windows updates > Update rings > Create profile (o Devices > Manage updates > Windows updates).
  2. Nombre LAB-Ring-Piloto.
  3. En Update ring settings define Quality update deferral (por ejemplo 2 dias) y Feature update deferral (por ejemplo 7 dias); configura la ventana de reinicio activa.
  4. Assignments: grupo LAB-Windows. Create.
  5. Observa que este anillo es el mecanismo base; Autopatch se apoyaria en un modelo de anillos similar.

Tarea 4 - Autopilot device preparation policy

  1. Ve a Devices > Windows > Enrollment (o Device onboarding > Enrollment) y localiza Device preparation policies dentro de Windows Autopilot.
  2. Create una device preparation policy. Asigna un grupo de dispositivos objetivo.
  3. Configura el modo de despliegue user-driven, el tipo de union Microsoft Entra join y el device name template.
  4. En la configuracion, selecciona las apps y scripts que deben instalarse durante el aprovisionamiento (esto alimenta el ESP).
  5. Guarda. Nota la diferencia frente a un deployment profile clasico (Devices > Windows > Windows enrollment > Deployment Profiles): compara ambos para el examen.

Tarea 5 - App protection policy (MAM)

  1. Ve a Apps > App protection policies > Create policy y elige Android (o iOS/iPadOS).
  2. En Apps selecciona apps gestionadas (por ejemplo Outlook y Edge).
  3. En Data protection activa Prevent backups, Restrict cut, copy, and paste between other apps: Policy managed apps y Save copies of org data: Block.
  4. En Access requirements exige PIN for access y un numero minimo de digitos.
  5. Assignments: grupo de usuarios de prueba. Create.
  6. Comprueba el estado en Apps > Monitor > App protection status. Esta politica protege datos incluso en dispositivos no inscritos (BYOD).

Tarea 6 - Proactive remediation (Endpoint Analytics)

  1. Ve a Reports > Endpoint Analytics > Proactive remediations (o Devices > Monitor > Remediations).
  2. Create script package. Ponle nombre (por ejemplo LAB-CheckDiskSpace).
  3. Sube un detection script de PowerShell (que devuelva exit code 1 si detecta el problema) y un remediation script (que lo corrija).
  4. Configura Scope tags si procede y una programacion (por ejemplo diaria).
  5. Assignments: grupo LAB-Windows. Create.
  6. Revisa resultados en la pestana Overview del paquete: verás dispositivos con problema detectado y corregido.

Cierre del laboratorio

  • Confirma que la VM aparece Compliant, con el perfil de Settings Catalog aplicado y el update ring asignado.
  • Revisa Devices > Monitor para ver el estado de cada politica.
  • Limpia el entorno al terminar (retira asignaciones o elimina las politicas de prueba) para dejar el tenant ordenado.
  • Repite mentalmente que decision de diseno representa cada tarea: son exactamente el tipo de escenario que pregunta el MD-102.

Caso practico integrador

Caso practico integrador: gestion moderna de endpoints de principio a fin

Este caso cruza los cinco dominios del MD-102 en un unico escenario, al estilo de los case studies del examen. Lee primero el contexto y luego responde las preguntas de decision; al final tienes claves de solucion para autocorregirte.

Contexto: Nordwind Salud

Nordwind Salud es una organizacion sanitaria con 1.800 empleados y tres perfiles de dispositivo:

  • Personal clinico (900): portatiles Windows 11 corporativos que deben aprovisionarse sin que TI los toque fisicamente, porque llegan directos del fabricante a cada centro.
  • Personal administrativo (600): equipos Windows 11 corporativos ya existentes, mas algunos macOS de direccion.
  • Personal externo y colaboradores (300): usan sus propios moviles Android e iPhone (BYOD) para consultar correo y una app de linea de negocio con datos de pacientes.

Requisitos de negocio y cumplimiento:

  1. Ningun dispositivo debe acceder a Exchange Online, SharePoint ni a la app clinica si no es compliant o, en BYOD, si la app no esta protegida.
  2. Los datos de pacientes no pueden copiarse desde la app corporativa a apps personales en los moviles BYOD.
  3. Los portatiles clinicos deben estar cifrados, con clave de recuperacion recuperable por el service desk y por el propio usuario.
  4. Un equipo de soporte regional solo debe poder gestionar los dispositivos de su centro, no los de toda la organizacion.
  5. Las actualizaciones deben desplegarse por fases para no interrumpir turnos, con seguridad critica sin reinicio siempre que sea posible.
  6. Direccion quiere un cuadro de mando de experiencia de usuario y alertas cuando falle una inscripcion o un dispositivo deje de cumplir.

Preguntas de decision

P1 (D1 - identidad e inscripcion). ¿Que tipo de union a Entra ID y que metodo de inscripcion eliges para cada perfil? Justifica el caso de los portatiles clinicos que llegan del fabricante y el de los moviles BYOD.

P2 (D1 - identidad, RBAC y cumplimiento). ¿Como das al soporte regional acceso solo a los dispositivos de su centro? ¿Que combinacion de politica de cumplimiento y Acceso Condicional satisface el requisito 1? ¿Que anades para cubrir el cifrado con recuperacion self-service del requisito 3?

P3 (D2 - despliegue y configuracion). Para los portatiles clinicos zero-touch, ¿eliges Autopilot deployment profile o device preparation policy, y que modo (user-driven, pre-provisioning, self-deploying)? ¿Que papel juega el ESP? ¿Como aplicas una linea base de configuracion comun con Settings Catalog solo a los equipos clinicos?

P4 (D3 - proteccion y actualizaciones). Disena la estrategia de seguridad de endpoint (baseline, ASR, cifrado) y de actualizaciones para cumplir los requisitos 3 y 5. ¿Donde encajan Autopatch y Hotpatch? ¿Como integras Defender for Endpoint?

P5 (D4 - apps y proteccion de datos). ¿Como despliegas la app clinica de linea de negocio en los distintos perfiles? Para los moviles BYOD, ¿que politica evita la fuga de datos del requisito 2 sin gestionar todo el dispositivo?

P6 (D5 - operaciones). ¿Que herramientas usas para el cuadro de mando de experiencia y para las alertas de inscripcion y cumplimiento del requisito 6? ¿Como automatizarias una comprobacion de cumplimiento personalizada que Intune no trae de serie?

Claves de solucion

P1. Portatiles clinicos y administrativos corporativos: Microsoft Entra join con inscripcion automatica en Intune. Los clinicos, al venir del fabricante, se registran en Windows Autopilot para aprovisionamiento zero-touch. Los macOS de direccion: inscripcion corporativa via Apple Business Manager (ADE). Los moviles BYOD no se unen ni se inscriben en MDM: se gestionan solo a nivel de app con MAM/app protection, para no tocar los datos personales del colaborador.

P2. Soporte regional: scope tags por centro y scoped admin con un rol RBAC que solo alcance los objetos etiquetados; opcionalmente multi-admin approval para cambios sensibles. Requisito 1: una compliance policy por plataforma (cifrado, version minima, antivirus) mas una politica de Acceso Condicional que exija require compliant device para Exchange/SharePoint; en BYOD, CA que exija app protection policy. Requisito 3: disk encryption policy de BitLocker con recuperacion self-service activada y claves almacenadas en Entra ID.

P3. Para hardware nuevo entregado a usuarios, lo moderno es una Autopilot device preparation policy en modo user-driven (el usuario inicia sesion y el equipo se aprovisiona). Si TI quiere preparar el equipo antes de entregarlo, pre-provisioning; self-deploying se reserva a dispositivos sin usuario (kioscos), que no es el caso clinico. El ESP bloquea el escritorio hasta que se instalan apps y politicas criticas, garantizando que el equipo llega listo. La linea base comun se crea con un perfil de Settings Catalog asignado a un grupo dinamico de equipos clinicos y, si hace falta, afinado con un assignment filter.

P4. Aplica un security baseline de Windows/MDE como punto de partida, reglas ASR, disk encryption policy (ya citada) y App Control for Business. Integra Defender for Endpoint haciendo onboarding desde Intune y desplegando politicas EDR. Actualizaciones por fases: update rings con diferimientos escalonados y ventanas fuera de turno; Windows Autopatch para automatizar Windows/Office/Edge/Teams por anillos; Hotpatch para seguridad critica sin reinicio; Delivery Optimization para no saturar la red de los centros.

P5. App clinica: en equipos gestionados, como app LOB o Win32 asignada por grupo; en moviles BYOD, se distribuye como app gestionada con app configuration policy y, sobre todo, una app protection policy (MAM) que cifre los datos, exija PIN y bloquee copiar/pegar y "guardar como" hacia apps personales (requisito 2), sin inscribir el dispositivo.

P6. Endpoint Analytics para el cuadro de mando de experiencia (startup score, device health, app reliability). Reporting de Intune con workbooks y alertas/notificaciones configuradas para enrollment failures y compliance drift (requisito 6). Una comprobacion de cumplimiento a medida se implementa extendiendo compliance con PowerShell (custom compliance scripts) o automatizando via Microsoft Graph; los agentes de Security Copilot en Intune pueden ademas recomendar acciones y priorizar incidencias.

Recursos para preparar el MD-102

Enlaces oficiales de Microsoft y consejos de laboratorio para preparar el examen MD-102: Endpoint Administrator. Toda la documentacion oficial esta en learn.microsoft.com.

Guia y pagina del examen

Practica oficial

Learning paths y modulos (Microsoft Learn)

Documentacion de producto

Comunidad y soporte

Consejos de laboratorio

  • Tenant de pruebas gratuito: solicita una prueba de Microsoft Intune (trial de 30 dias) o usa el programa Microsoft 365 Developer si dispones de el. Nunca practiques wipe, retire o politicas de CA en un tenant de produccion.
  • Licencias: para probar Autopilot automatic enrollment y compliance + CA necesitas licencias que incluyan Intune y Entra ID P1/P2. La Intune Suite (EPM, Cloud PKI, Remote Help, Tunnel, Advanced Analytics) es un add-on de pago; existen trials para probarla.
  • Dispositivos de prueba: una VM de Windows 11 sirve para inscripcion, Settings Catalog, compliance y update rings. Para Autopilot registra el hash de hardware de la VM. Un emulador o dispositivo Android/iOS de descarte ayuda con MAM y app protection.
  • Orden recomendado en el lab: primero identidad e inscripcion, luego cumplimiento + Acceso Condicional, despues configuracion y apps, y por ultimo seguridad, actualizaciones y monitorizacion. Es el mismo orden del examen.
  • Automatizacion: instala el modulo Microsoft.Graph.Intune o usa Graph Explorer (developer.microsoft.com/graph/graph-explorer) para practicar consultas y cambios via API sin tocar el portal.

Evaluacion

Criterios de evaluacion y autoevaluacion (MD-102)

Como saber si estas listo para presentarte al MD-102. El objetivo del examen es 700/1000; en autoevaluacion, apunta a acertar de forma estable el 80% o mas de las preguntas de practica antes de agendar, porque la ponderacion real deja poco margen.

Rubrica de preparacion por dominio

Puntuate de 1 (no lo domino) a 4 (lo explico y lo aplico sin ayuda) en cada dominio. Estas listo cuando ningun dominio esta por debajo de 3 y los de mayor peso (D1 y D2) estan en 4.

Dominio Peso Estas al nivel si... Objetivo minimo
D1. Preparar infraestructura 20-25% Eliges el join type y el metodo de inscripcion correctos por escenario, creas grupos dinamicos, scope tags, compliance + CA, Hello y LAPS 4
D2. Gestionar y mantener 25-30% Distingues device preparation de deployment profile y los 3 modos de Autopilot, configuras ESP, Settings Catalog, filtros, Windows 365 y acciones remotas 4
D3. Proteger dispositivos 15-20% Separas baseline, compliance y endpoint security policy; configuras ASR, cifrado, Defender EDR y update rings/Autopatch/Hotpatch 3+
D4. Gestionar apps 15-20% Despliegas Win32/LOB/Store/M365, VPP; distingues app protection (MAM) de app configuration y de MDM 3+
D5. Optimizar operaciones 10-15% Automatizas con PowerShell/Graph, interpretas Endpoint Analytics y proactive remediations, usas agentes de Security Copilot y configuras reporting/alertas 3

Checklist "ready to sit the exam"

Marca todo antes de agendar:

  • [ ] Explico sin notas los tres tipos de union a Entra ID y cuando usar cada uno.
  • [ ] Se decidir entre grupo asignado y grupo dinamico y escribir una regla de pertenencia.
  • [ ] Conozco los metodos de inscripcion por plataforma (Windows automatic, ABM, Android Enterprise, Knox, Zero-Touch) y las enrollment restrictions.
  • [ ] Diferencio compliance policy, security baseline y endpoint security policy sin dudar.
  • [ ] Configuro una politica de Acceso Condicional que exige dispositivo compliant.
  • [ ] Entiendo scope tags, scoped admin y multi-admin approval.
  • [ ] Decido entre device preparation policy y deployment profile de Autopilot y justifico los tres modos (user-driven, pre-provisioning, self-deploying).
  • [ ] Se para que sirve el ESP y como bloquea el acceso hasta terminar.
  • [ ] Creo un perfil con Settings Catalog y lo afino con un assignment filter.
  • [ ] Conozco Windows 365 (provisioning policy, red, imagen) y Windows Backup.
  • [ ] Diferencio retire de wipe y se que acciones remotas existen (incluida device query con KQL).
  • [ ] Configuro ASR, cifrado BitLocker con recuperacion self-service y App Control for Business.
  • [ ] Integro Intune con Defender for Endpoint (onboarding + politicas EDR).
  • [ ] Diseno update rings y se donde encajan Autopatch, Hotpatch y Delivery Optimization.
  • [ ] Despliego apps Win32 (.intunewin), LOB, Store, M365 y VPP.
  • [ ] Distingo app protection policy (MAM, tambien BYOD) de app configuration policy.
  • [ ] Automatizo tareas con PowerShell y Microsoft Graph.
  • [ ] Interpreto Endpoint Analytics y creo una proactive remediation.
  • [ ] Se que aportan los agentes de Security Copilot en Intune.
  • [ ] He completado el Practice Assessment oficial con >=80% de forma consistente.

Umbrales de decision

  • Menos del 65% en practica: vuelve a los modulos, no agendes todavia.
  • 65-79%: estas cerca; refuerza los dominios donde fallas y repite el Practice Assessment.
  • 80% o mas de forma estable, con la checklist completa: agenda el examen.

Actividades de validacion

  • Redacta un mini decision memo justificando join type, inscripcion, cumplimiento y CA para una organizacion ficticia.
  • Explica a otra persona la diferencia entre baseline, compliance y endpoint security policy.
  • Resuelve al menos un case study completo cronometrado, como los del caso practico integrador.
← Volver a Puesto de Trabajo Digital