Windows Autopilot & Intune MDM Provisioning

Windows Autopilot & Intune MDM Provisioning

Status: COMPLETE
Completion date: 2026-09-22

Project objective

Build and validate a portfolio-quality Windows Autopilot and Microsoft Intune pilot demonstrating device registration, user-driven Microsoft Entra join, automatic Intune enrollment, branded OOBE, Enrollment Status Page controls, required Microsoft 365 Apps deployment, compliance evaluation, BitLocker, Microsoft Defender, Windows Firewall, Virtualization Based Security, Secure Boot, and post-enrollment management.

Environment

• Microsoft Entra verified domain: jeremyfontenot.online
• On-premises AD DS domain: ad.jeremyfontenot.online
• Autopilot mode: user-driven
• Join type: Microsoft Entra joined
• Pilot user group: SG-Intune-Autopilot-Pilot-Users
• Pilot device group: SG-Intune-Autopilot-Pilot-Devices
• Autopilot deployment profile: AP UserDriven EntraJoin Pilot
• Enrollment Status Page: ESP Autopilot Pilot
• Required application: M365 Apps Autopilot Pilot
• Compliance policy: Compliance Windows Autopilot Pilot
• Security configuration: Config Windows Autopilot Security Pilot

End-to-end result

A registered physical Lenovo endpoint was safely backed up, reset to Windows OOBE, and successfully completed the live Windows Autopilot deployment flow.

Validated outcomes include branded OOBE, Microsoft Entra join, Intune MDM enrollment, Enrollment Status Page completion, required Microsoft 365 Apps deployment, BitLocker, Defender, Windows Firewall, VBS, Secure Boot remediation, final Intune compliance, Settings Catalog success, and a separate administrative elevation path while the Autopilot user remained standard.

Security and evidence handling

Public evidence excludes passwords, recovery keys, MFA codes, private SSH keys, OpenVPN credentials, 1Password recovery material, browser password exports, and other secrets. Unique hardware and directory identifiers are redacted from public screenshots and command output.

See evidence/README.md for the evidence index.

Architecture

Logical design

The pilot separates user-scoped enrollment enablement from device-scoped Autopilot configuration.

User scope

SG-Intune-Autopilot-Pilot-Users scopes automatic Intune MDM enrollment to the pilot.

Device scope

SG-Intune-Autopilot-Pilot-Devices targets the Autopilot deployment profile, Enrollment Status Page, Microsoft 365 Apps required deployment, compliance policy, and Windows Settings Catalog security configuration.

Runtime flow

1. Device hardware identity is registered with Windows Autopilot.
2. The device receives the user-driven Microsoft Entra join profile.
3. Tenant branding is displayed during OOBE.
4. The pilot user authenticates and the device joins Microsoft Entra ID.
5. Automatic Intune MDM enrollment occurs.
6. Enrollment Status Page blocks completion while required configuration and Microsoft 365 Apps are processed.
7. The device reaches the Windows desktop.
8. Endpoint-side PowerShell and Intune portal evidence validate the resulting security state and compliance.

Security controls

The compliance policy evaluates BitLocker, Secure Boot, code integrity, storage encryption, Windows Firewall, TPM, antivirus, antispyware, Microsoft Defender Antimalware, current security intelligence, and real-time protection.

The Settings Catalog profile applies BitLocker/device encryption settings, Defender protections, PUA blocking, VBS, and Windows Firewall enablement for Domain, Private, and Public profiles.

The enrolled pilot user remains a standard user. Administrative elevation is provided separately through the Microsoft Entra Device Administrators role.

Project 1 Evidence Index

Public evidence is sanitized. Passwords, recovery keys, MFA codes, private keys, VPN configuration contents, browser password exports, recovery codes, device IDs, certificate thumbprints, and hardware serial numbers are excluded or redacted.

Screenshots

1. screenshots/01-autopilot-branded-oobe.webp — Autopilot retrieved the tenant experience and displayed custom work/school branding.
2. screenshots/02-esp-device-preparation.webp — Enrollment Status Page began device preparation.
3. screenshots/03-esp-device-setup-complete.webp — Device preparation and device setup completed while account setup continued.
4. screenshots/04-compliance-before-remediation.webp — Compliance policy identified BitLocker and Secure Boot as not compliant; device identifier redacted.
5. screenshots/05-intune-final-compliant.webp — Final Intune inventory showed the corporate device compliant; device identifier and UPN redacted.
6. screenshots/06-settings-catalog-success.webp — Settings Catalog check-in reported 2 succeeded, 0 errors, 0 conflicts, 0 not applicable, 0 in progress.

Command evidence

• 01-dsregcmd-sanitized.txt
• 02-intune-enterprisemgmt-tasks-sanitized.txt
• 03-m365-apps-validation.txt
• 04-bitlocker-validation.txt
• 05-defender-validation.txt
• 06-firewall-vbs-secureboot-validation.txt

See validation.md for the consolidated validation matrix.

Implementation

1. Pilot-scoped automatic MDM enrollment

Automatic Intune enrollment was scoped to SG-Intune-Autopilot-Pilot-Users.

2. Autopilot registration and targeting

A physical Lenovo endpoint was registered with Windows Autopilot and added to SG-Intune-Autopilot-Pilot-Devices. The device later reported the deployment profile as assigned.

3. User-driven Microsoft Entra join

AP UserDriven EntraJoin Pilot was configured for user-driven Microsoft Entra join, standard-user provisioning, and the device naming template AP-%SERIAL%.

4. Microsoft Entra branding

Custom background, banner, square logo, sign-in hint, and lab-specific sign-in text were configured and observed during live OOBE.

5. Enrollment Status Page

ESP Autopilot Pilot displayed provisioning progress and blocked completion while the required application and device configuration were processed.

6. Microsoft 365 Apps

M365 Apps Autopilot Pilot was required for the pilot device group. Post-enrollment validation confirmed O365ProPlusRetail on x64 Click-to-Run.

7. Compliance and remediation

Compliance Windows Autopilot Pilot initially reported BitLocker and Secure Boot as noncompliant. Local validation showed BitLocker was already fully encrypted while Secure Boot was disabled. Secure Boot was enabled in firmware and Intune was synchronized; the device then reported compliant.

8. Security configuration

Config Windows Autopilot Security Pilot applied BitLocker, Defender, firewall, PUA, and VBS controls. Final Intune check-in status showed 2 succeeded, 0 errors, 0 conflicts, 0 not applicable, and 0 in progress.

9. Administrative access

The Autopilot user remained a standard user. A separate tenant administrator was assigned the Microsoft Entra Device Administrators role. UAC elevation was validated before running administrative endpoint checks.

10. Safe reset preparation

Before destructive reset, selected lab/business data and recovery-critical configuration were backed up to an SMB share. Secret-bearing recovery files are intentionally excluded from this public repository.

Lessons Learned

1. Pilot-scoped groups reduce blast radius and simplify troubleshooting.
2. Assigned or Active is not proof of endpoint enforcement; validate the resulting device state.
3. End-to-end validation matters more than portal configuration screenshots.
4. Backup and recovery readiness are part of change management for destructive enrollment testing.
5. Keep normal users standard and provide a separate administrative elevation path.
6. runas is not the same as UAC elevation; validate the actual token.
7. Troubleshoot compliance from both endpoint evidence and the Intune management plane.
8. Firmware settings such as Secure Boot can determine cloud compliance.
9. Endpoint-side PowerShell plus Intune portal status provides stronger evidence than either source alone.
10. Never publish recovery codes, private keys, VPN profiles, browser password exports, or BitLocker recovery values.

Portfolio Summary

Windows Autopilot & Intune MDM Provisioning

Implemented and validated an end-to-end Windows Autopilot deployment using Microsoft Intune and Microsoft Entra ID.

The project uses dedicated pilot user/device groups, user-driven Microsoft Entra join, automatic Intune MDM enrollment, custom Entra branding, Enrollment Status Page controls, required Microsoft 365 Apps deployment, Windows compliance, and a Settings Catalog security baseline.

A registered physical Lenovo endpoint was safely backed up, reset to OOBE, and provisioned through the live Autopilot workflow. Post-enrollment validation confirmed Entra join, Intune management, Microsoft 365 Apps, BitLocker, Defender, Windows Firewall, VBS, Secure Boot, and final Intune compliance.

A real compliance issue was identified and remediated: Secure Boot was disabled in firmware. After enabling Secure Boot and synchronizing the endpoint, Intune reported the device compliant.

The Autopilot user remains a standard user. Administrative elevation is provided separately through the Microsoft Entra Device Administrators role.

Status: COMPLETE

Troubleshooting

Autopilot profile propagation

Profile assignment did not appear immediately. A service sync and propagation wait were used before the device reported Assigned.

ESP assignment display

An ESP assignment temporarily appeared stale/soft-deleted even though the target group existed. Refreshing the portal restored the correct Active state without rebuilding the group.

Branding asset limits

The original background exceeded Microsoft Entra upload limits. It was recompressed while retaining the required dimensions.

Safe backup before reset

Because the Autopilot target was also the administrative laptop, destructive reset was delayed until a dedicated SMB backup target and independent OpenVPN recovery path were validated.

Standard user and elevation

The Autopilot profile intentionally created a standard user. BitLocker management commands failed from the standard session. Assigning a separate Entra account to Device Administrators provided the supported administrative path. A filtered runas token still showed the Administrators SID as deny-only; a true UAC elevation produced an enabled Administrators token.

Initial compliance failure

The first compliance report showed BitLocker and Secure Boot as not compliant. Local BitLocker validation showed the OS volume was already fully encrypted. Confirm-SecureBootUEFI returned False, identifying the real firmware gap. Secure Boot was enabled in UEFI, then an Intune sync was performed. Final compliance changed to Compliant.

Management boundary

After Autopilot, the endpoint is Microsoft Entra joined and Intune-managed rather than AD DS domain joined. Intune/MDM is the authoritative management path for this project endpoint.

Validation

Final validation matrix

Sanitized command highlights

Entra join and SSO

AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : NO
DeviceAuthStatus : SUCCESS
TpmProtected : YES
AzureAdPrt : YES

Microsoft 365 Apps

ProductReleaseIds : O365ProPlusRetail
Platform          : x64

BitLocker

Conversion Status    : Fully Encrypted
Percentage Encrypted : 100.0%
Encryption Method    : XTS-AES 128
Protection Status    : Protection On
Key Protectors       : Numerical Password, TPM

Defender

AntivirusEnabled          : True
AntispywareEnabled        : True
RealTimeProtectionEnabled : True
BehaviorMonitorEnabled    : True
IoavProtectionEnabled     : True

Firewall

Domain  True
Private True
Public  True

VBS

VirtualizationBasedSecurityStatus : 2

Secure Boot

Confirm-SecureBootUEFI
True

No recovery keys, passwords, tokens, device IDs, certificate thumbprints, or hardware serial numbers are included.