Objective
Deploy a traditional Windows Autopilot user-driven Microsoft Entra join pilot. This guide separates device registration, profile assignment, join state, Intune enrollment and user validation. Windows Autopilot device preparation is a different workflow; check its requirements before applying these registration steps.
- Keep the pilot group separate from the wider fleet.
- Treat local hardware-hash export and online tenant upload as different actions.
- Preserve existing device data before any reset; do not repeatedly wipe a failed pilot without retaining logs.
Prerequisites
- Supported Windows edition/build and the licensing, network access and Entra/Intune configuration required by the selected scenario.
- Pilot devices, verified serial numbers, an authorized enrollment user and appropriate management roles.
- A backup of any pilot-device data before a reset or OOBE test.
- Documented deployment profile, ESP settings, required apps and intended management outcome.
Step-by-step procedure
Establish the baseline and scope
Record the pilot scenario, device serial numbers, tenant, user and intended join/management state. Confirm registration and profile assignment before starting OOBE. Preserve any existing user data before the separately approved reset.
- The selected devices or site, timing, previous state and expected result are recorded.
Register the intended pilot devices
For traditional Windows Autopilot, prefer OEM or partner registration for new hardware. For a manual pilot, collect the hardware identity using the documented method, then verify the serial number and tenant before registration. Local CSV export and Online upload are alternative paths with different effects. Keep hardware-identity files in a protected location and confirm successful device registration.
- The intended serial numbers are registered in the correct tenant; a local CSV alone is not registration.
Assign and verify the OOBE profile
Create a group containing only the pilot devices and assign the intended deployment profile. For this user-driven Microsoft Entra join pilot, check deployment mode, account type and OOBE settings. Confirm group membership and profile assignment before starting the device; a saved profile is not proof that the device has received it.
- The pilot device shows the intended deployment-profile assignment before OOBE begins.
Verify the actual join state
After provisioning, inspect dsregcmd /status in the intended user context and check the tenant and device identity. For the Microsoft Entra join scenario in this guide, the expected device state is AzureAdJoined YES and DomainJoined NO. Compare the device record in Entra; do not confuse workplace registration with an Entra-joined device.
- The device and tenant match the planned join scenario, with unexpected hybrid or registration-only states investigated.
Validate Intune enrollment separately
Confirm the pilot device appears as managed in Intune with the expected user, recent synchronization and enrollment result. Review the assigned enrollment scope, licensing and restrictions if enrollment fails. MDM URLs in dsregcmd output describe tenant configuration and do not by themselves prove that this device is enrolled or managed.
- Management state is confirmed from the device record and synchronization evidence, independently of the join check.
Test the required apps and ESP
Use a small set of genuinely required applications for the pilot. Configure Enrollment Status Page behavior and observe the exact app or setup phase when deployment stops. Check assignment, install context, detection and dependencies rather than skipping a blocking application without explanation. After reaching the desktop, open the applications used by the pilot user.
- Required applications install and launch, or the precise blocking app and evidence are recorded.
Check effective device policy
Review configuration, compliance, certificates, network access and recovery-key handling against the intended design. Separate assignment from the device’s reported effective state, and investigate conflicting settings or filters. Verify that the pilot can use the services needed for work without broad policy relaxations that conceal an enrollment problem.
- The pilot receives the intended policy and passes the agreed access and recovery checks.
Expand only after a reproducible pilot
Record OOBE duration, failed phases, app results and support interventions across representative pilot devices. Correct the demonstrated problems before adding the next small group. Keep a clear stop criterion and recovery plan. Registration, profile assignment, device reset and management enrollment are separate operations; removing a profile assignment does not automatically deregister a device.
- The next wave has explicit acceptance criteria and can be stopped without resetting unrelated devices.
Validate the complete service
Complete the subject-specific validation below and retain the result and evidence. A command or setup phase that succeeds does not on its own establish that the whole service is ready.
- The complete intended workflow is checked using the criteria below.
Examples: observations and changes
These are separate examples, not one script to run in sequence. Follow the current Microsoft collection method from an approved source. The local example creates C:\HWID and writes C:\HWID\AutopilotHWID.csv; use a protected location and preserve any existing export. The Online example is an alternative tenant upload with sign-in and consent, not a second local observation.
Optional process-scoped execution policy for the approved collection method; do not override managed policy
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSignedInstall the documented collection script from an approved source; review its version before use
Install-Script -Name Get-WindowsAutopilotInfo -Scope CurrentUserLocal collection: create the example directory and export a hardware-hash CSV; choose a protected output location
New-Item -ItemType Directory -Path 'C:\HWID' -Force | Out-Null
Get-WindowsAutopilotInfo -OutputFile 'C:\HWID\AutopilotHWID.csv'Alternative online registration: uploads device identity to the selected tenant and requires authorized sign-in/consent
Get-WindowsAutopilotInfo -OnlineObservation: inspect the join state after provisioning in the intended user context
dsregcmd /statusValidation
The procedure is validated when:
- The intended device receives the correct deployment profile and completes the agreed OOBE/ESP path.
- Entra identity, tenant and Intune management state are verified independently.
- Required applications, access, compliance and recovery information meet the pilot criteria.
Rollback
- Stop adding devices to the next wave while the failure is unresolved.
- Restore the pilot’s intended profile and policy targeting through the management system.
- Do not delete Entra/Intune records, deregister or reset devices without the separate recovery plan and protected user data.
Troubleshooting / common errors
- Wrong OOBE experience: compare device registration, tenant, group membership and profile assignment.
- Join is correct but management fails: inspect licensing, MDM scope and enrollment restrictions separately.
- ESP stalls: retain the exact phase and app diagnostic result before resetting again.
- Device preparation was chosen: follow its own workflow instead of assuming the traditional hardware-hash registration path.
Official references
Keep the scope, original state, observed evidence and validated outcome with the procedure record. Consult the official documentation for the installed version.