Microsoft MD-102: Device Enrollment and Azure AD Join — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #md-102 #certification #exam-prep #study-guide

Part of the Microsoft Endpoint Administrator Associate MD-102 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Device enrollment determines device identity, trust, and management boundaries in Microsoft Entra ID (formerly Azure AD) and Intune. On Windows, there are three primary device states with distinct use cases:

Azure AD Join (AADJ): The device is cloud-joined to Entra ID and typically auto-enrolled into Intune. Use AADJ for cloud-first organizations, remote/hybrid work, and when you want passwordless sign-in (Windows Hello for Business), modern device-based Conditional Access, and zero on-premises dependency. Ideal with Windows Autopilot user-driven or self-deploying modes. Requires appropriate licensing (Intune and Entra ID P1 for auto-enrollment).
Hybrid Azure AD Join (HAADJ): The device is joined to on-premises Active Directory and registered in Entra ID. Use HAADJ when you still require Group Policy, legacy Kerberos/NTLM authentication, or on-premises domain dependencies. For Autopilot HAADJ, you need the Intune Connector for Active Directory (offline domain join) and careful network/VPN planning to satisfy domain requirements.
Workplace Join (Azure AD Registered): The user registers a personal or non-domain Windows device to Entra ID. The device can be MDM-enrolled, but it does not participate in Windows logon with Entra ID, and it lacks device-based SSO at the OS level. Use it for BYOD scenarios and with Mobile Application Management (MAM) to protect corporate data without forcing full device management.

These join states underpin Conditional Access posture, compliance reporting, SSO, and lifecycle operations (wipe/retire/delete). Selecting the correct join state dictates your enrollment workflow, the security controls you can enforce, and the end-user experience.

Windows Autopilot and Enrollment Orchestration

Windows Autopilot replaces traditional imaging with a cloud-driven provisioning flow that applies identity, device configuration, and applications during the Out-of-Box Experience (OOBE).

User-driven mode: The user signs in at OOBE, and the device completes AADJ or HAADJ, enrolls into Intune, and applies policies/apps. Use for knowledge workers and assigned laptops/desktops. Supports configuring the user as a standard or local admin in the deployment profile.
Self-deploying mode: Zero-touch provisioning for devices without primary users (kiosks, digital signage). Requires TPM 2.0 with device attestation, AADJ, and network connectivity at OOBE. No user interaction; the device enrolls and applies required profiles/apps automatically.
Pre-provisioning (formerly White Glove): A technician or OEM pre-downloads and applies apps, policies, and updates before the device is handed to the end user, who completes a short sign-in phase. Start the pre-provisioning technician phase at OOBE (press Windows key five times). Use this to front-load large app payloads and reduce day-one user wait time.

Autopilot deployment profiles define the OOBE experience and core join behavior:

Join type (Azure AD Join or Hybrid Azure AD Join)
User account type (Administrator or Standard)
OOBE customizations (skip privacy settings, EULA, region/language, and OEM pre-provisioning)
Device name templates (for AADJ), and language/keyboard options

The Enrollment Status Page (ESP) controls whether users can reach the desktop before required policies, security baselines, and apps install. Configure ESP to:

Block until required apps install or time out with retry logic
Track all or a curated list of required Win32/LOB/Store apps
Allow log collection on failure to enable supportability during Autopilot deployments

Device group tags are metadata on Autopilot device records used to drive Azure AD dynamic device group membership for profile and app assignments. Common patterns include dynamic rules that filter on devicePhysicalIds for ZTDID and [OrderID]:<GroupTag> to target the correct deployment profile and configurations the moment the hardware hash is imported.

Cross-Platform Enrollment: Apple and Android

Apple platforms

Apple Business Manager (ABM) and Apple School Manager (ASM) integrate with Intune to deliver Automated Device Enrollment (ADE) for iOS/iPadOS and macOS. ADE provides zero-touch enrollment, supervision for iOS/iPadOS, and “User Approved MDM” status for macOS, unlocking advanced management features (e.g., kernel/system extensions approvals, FileVault key escrow with bootstrap token).
Prerequisites: Create and renew an Apple MDM push certificate (.pem) in the Apple Push Certificates Portal. Connect ABM/ASM to Intune by uploading the ABM/ASM server token (.p7m) generated after you upload Intune’s public key to ABM/ASM. Assign devices to the Intune MDM server in ABM/ASM and configure Intune enrollment profiles (Setup Assistant screens, device naming, supervision, and whether MDM enrollment is mandatory and non-removable).
Apps and Books (formerly VPP) integration via a location token enables license-based app deployment without Apple IDs on supervised devices.
Apple Configurator enrollment supports devices not purchased through ABM/ASM. It can add iOS/iPadOS devices to ABM/ASM (iOS 11+ with 30-day provisional period) and provides macOS enrollment via Configurator with automated enrollment profiles.

Android platforms (Android Enterprise)

Work profile (BYOD): Creates a separate, encrypted work container on personally owned devices, isolating corporate data. Requires the Company Portal and Managed Google Play. Use for bring-your-own scenarios with strong privacy separation. Conditional Access can require compliant work profiles before app access.
Fully managed (corporate-owned, user-affinity): The organization controls the entire device with user sign-in. Use for COBO scenarios needing strong device posture, restrictions, and broad app deployment. Enrollment can use QR code, NFC, or Zero-touch enrollment.
Dedicated (corporate-owned, no user): Locked-down shared or kiosk devices, often single- or multi-app. Enrollment uses QR/NFC/Zero-touch. In Intune device restrictions, kiosk behavior is configured under Device experience. Use for retail, floor units, or shared scanners where personal use is disallowed.

For Android Zero-touch (Google) and Knox Mobile Enrollment (Samsung), assign the Intune enrollment profile at procurement for a seamless out-of-box experience.

Intune Automatic Enrollment, Bulk Provisioning, and Restrictions

Intune automatic enrollment is configured in Microsoft Entra ID under Mobility (MDM and MAM) for Microsoft Intune:

MDM user scope: Controls which users’ devices automatically enroll in Intune when AADJ or Azure AD registration occurs. Set to All or a scoped group to ensure frictionless enrollment for cloud-joined and registered devices. Requires Intune and Entra ID P1 licenses assigned to users.
MAM user scope: Targets users for app protection (MAM) without device enrollment for supported platforms. On Windows, it historically targeted Windows Information Protection (WIP) MAM-we scenarios. Use MAM when you need data protection and Conditional Access on unmanaged/BYOD devices without imposing full MDM.

Bulk enrollment using provisioning packages (Windows Configuration Designer, WCD) is practical for lab, kiosk, or air-gapped scenarios where Autopilot is unavailable:

Create a provisioning package (.ppkg) with WCD that configures device identity and management (e.g., enroll with a bulk Azure AD enrollment token, set local accounts, Wi-Fi profiles, and policy baselines).
Apply the .ppkg at OOBE (USB/SD) or at runtime. Bulk enrollment commonly yields devices with no primary user (shared) and limits user-affinity-dependent features like user-targeted app installs. Prefer Autopilot when hardware hashes and internet access are available; use .ppkg when you must provision offline or at scale without OEM/Azure preregistration.

Device enrollment restrictions enforce governance at the enrollment edge:

Platform restrictions: Globally or per-group, allow or block platforms (Windows, macOS, iOS/iPadOS, Android) and enrollment methods (e.g., block Android device administrator to force Android Enterprise).
OS version gates: Define minimum/maximum OS versions to block outdated or unsupported OS enrollments.
Personally owned limits: Block personal devices by platform to require corporate ownership (e.g., force ADE on iOS/iPadOS or Android Enterprise corporate-owned modes). Combine with corporate identifiers (IMEI/serial) to auto-mark ownership on enrollment.
Device limit restrictions: Cap the number of devices per user to prevent sprawl. Create group-scoped restrictions for exceptions (e.g., IT staff) and ensure priority ordering so specific restrictions override the default.

Examine assignment precedence and test both corporate and BYOD flows. Enrollment restrictions, automatic enrollment scope, and Autopilot assignments should align so that users receive the intended ownership path (corporate vs personal), the correct join state, and the right app/policy set at first sign-in.

Practical Problem Scenario

Adobe plans a global refresh to Windows 11 with a mix of corporate-owned laptops for staff, Android kiosks in briefing centers, and BYOD for contractors. They must minimize user downtime, enforce data separation on personal devices, and enable zero-touch for Apple hardware in design studios.

Implement Azure AD Join with Autopilot user-driven for staff laptops

Why: AADJ provides modern SSO, device-based Conditional Access, and seamless Intune enrollment. User-driven Autopilot reduces IT touch, sets users as standard accounts, and applies security baselines and required apps during OOBE with ESP enforced.

Use Autopilot pre-provisioning for regions with slow links

Why: Pre-provisioning front-loads large Win32 apps and updates so employees reach a productive desktop quickly. ESP blocks until the security stack is in place, and log collection on failure accelerates troubleshooting.

Configure Autopilot self-deploying for Windows kiosks

Why: Self-deploying mode enrolls and configures devices with no user interaction, ideal for lobbies and signage. TPM attestation ensures device trust; Device experience in Intune sets single-app or multi-app kiosk.

Set Intune MDM user scope to All and MAM user scope to a BYOD contractors group

Why: Automatic enrollment removes friction for employees. MAM scope enables app protection without enrollment for contractors, protecting corporate data in Microsoft 365 apps while respecting personal privacy.

Enforce enrollment restrictions

Why: Block personal Windows and Android enrollments for employees to ensure corporate ownership. Require Android Enterprise (block device administrator), set minimum OS versions (Windows 11/Android 11/iOS 15+), and limit devices per user to prevent unmanaged growth.

Integrate Apple Business Manager with Intune and deploy ADE

Why: ABM with ADE delivers zero-touch iOS/iPadOS/macOS enrollment, supervision for iOS/iPadOS, and User Approved MDM for macOS. Configure Setup Assistant screens to reduce prompts and push design apps via Apps and Books licensing without Apple IDs.

Configure Android Enterprise enrollments: fully managed for COBO and dedicated for kiosks

Why: Fully managed devices give IT full control and compliance enforcement for corporate phones. Dedicated mode secures shared Android signage/tablets; kiosk restrictions are applied under Device experience.

Use Zero-touch/Knox Mobile Enrollment for Android procurement

Why: Pre-assign Intune enrollment profiles at purchase so devices enroll on first boot without IT handling, ensuring consistent posture and rapid scale.

Apply dynamic device groups using Autopilot device group tags

Why: Group tags route hardware to the correct deployment profiles and app sets at import time, keeping assignment logic maintainable across business units and regions.

Reserve provisioning packages for edge cases

Why: Where sites are air-gapped or OEM registration is impossible, WCD .ppkg enables offline enrollment and baseline configuration. It complements Autopilot rather than replacing it, maintaining a consistent management model in Intune.

All domains · Device Configuration Profiles and Policies →

Practice these questions → · Timed practice on ExamRoll.io →