--- title: "Deploy Windows 11 with Autopilot and Eliminate Imaging" description: "Deploy Windows 11 with Autopilot: register hardware, create a device group and deployment profile, configure the Enrollment Status Page, and run a pilot." canonical: "https://adamtheautomator.com/deploy-windows-11-with-autopilot-and-eliminate-ima/" --- # Deploy Windows 11 with Autopilot and Eliminate Imaging > Deploy Windows 11 with Autopilot: register hardware, create a device group and deployment profile, configure the Enrollment Status Page, and run a pilot. Source: https://adamtheautomator.com/deploy-windows-11-with-autopilot-and-eliminate-ima/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Deploy Windows 11 with Autopilot and Eliminate Imaging](https://adamtheautomator.com/wp-content/uploads/publisher/3075d9c85b2b8183ae33f75335a368e3/d7884342486c98b914dbf1e37930ffe2699a57af2c88987f99eda885dcd63940.webp) # Deploy Windows 11 with Autopilot and Eliminate Imaging [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)15 September 202617 min. read Categories: [Cloud](/category/cloud/) Tags:[Intune](/tag/intune/)[Windows Client](/tag/windows-client/)[Endpoint Management](/tag/endpoint-management/)[Microsoft Entra](/tag/microsoft-entra/) Table of Contents * [What Is Windows Autopilot?](#what-is-windows-autopilot) * [Why Windows 11 Makes This the Moment to Move](#why-windows-11-makes-this-the-moment-to-move) * [Prerequisites](#prerequisites) * [Deciding the Deployment Path: Cloud Join, Hybrid Join, or Device Preparation](#deciding-the-deployment-path-cloud-join-hybrid-join-or-device-preparation) * [Cloud-Only Microsoft Entra Join](#cloud-only-microsoft-entra-join) * [Hybrid Microsoft Entra Join](#hybrid-microsoft-entra-join) * [Windows Autopilot Device Preparation](#windows-autopilot-device-preparation) * [Registering Devices With Windows Autopilot](#registering-devices-with-windows-autopilot) * [Registering Through an OEM or Partner](#registering-through-an-oem-or-partner) * [Registering Existing Devices With PowerShell](#registering-existing-devices-with-powershell) * [Importing the CSV and Syncing](#importing-the-csv-and-syncing) * [Creating the Autopilot Device Group](#creating-the-autopilot-device-group) * [Dynamic Device Group for One Pilot Device](#dynamic-device-group-for-one-pilot-device) * [Group Tags for Fleet Scale](#group-tags-for-fleet-scale) * [Creating and Assigning the Deployment Profile](#creating-and-assigning-the-deployment-profile) * [Out-of-Box Experience Settings](#out-of-box-experience-settings) * [Assigning the Profile and Reading Profile Status](#assigning-the-profile-and-reading-profile-status) * [Configuring the Enrollment Status Page](#configuring-the-enrollment-status-page) * [Core ESP Settings](#core-esp-settings) * [Choosing Blocking Apps and Timeout Math](#choosing-blocking-apps-and-timeout-math) * [Deploying Apps and Policies Ahead of First Sign-In](#deploying-apps-and-policies-ahead-of-first-sign-in) * [Packaging Apps for Reliable Provisioning](#packaging-apps-for-reliable-provisioning) * [Deploying and Verifying a Windows 11 Autopilot Pilot](#deploying-and-verifying-a-windows-11-autopilot-pilot) * [Running the First Deployment](#running-the-first-deployment) * [Verifying the Deployment](#verifying-the-deployment) * [Reprovisioning Windows 10-Era Hardware](#reprovisioning-windows-10-era-hardware) * [Troubleshooting Common Autopilot Failures](#troubleshooting-common-autopilot-failures) * [Where the Logs Hide](#where-the-logs-hide) * [Diagnosing the “Device Did Nothing” Complaint](#diagnosing-the-device-did-nothing-complaint) * [Frequently Asked Questions](#frequently-asked-questions) * [Next Steps](#next-steps) Before you build one more golden image for your next Windows 11 rollout, count what that image actually costs you. Every hardware refresh means recapturing drivers and resequencing applications, then babysitting a task sequence that breaks the moment a new laptop model shows up. Windows Autopilot exists to retire that workflow: the device boots into the standard out-of-box experience (OOBE), and the cloud turns the factory Windows install into a business-ready, policy-managed machine with no imaging step at all. If you’re ready to deploy Windows 11 with Autopilot, this guide is the full path from tenant prerequisites to a verified pilot device. By the end, you will have deployed one pilot machine end to end, so you will recognize the failures you meet along the way by their error codes before they can stall a live rollout. ## What Is Windows Autopilot? Recognizing those error codes starts with knowing what the service actually does to a device between power-on and desktop. Windows Autopilot is, in Microsoft Learn’s own words, “a collection of technologies used to set up and pre-configure new devices, getting them ready for productive use.” The device ships from the OEM with Windows already installed, and the [Windows Autopilot service](https://learn.microsoft.com/en-us/autopilot/overview) transforms that install into an organization-ready state with no reimaging step: joining the machine to Microsoft Entra ID, enrolling it in Microsoft Intune, applying policies, installing apps, and even changing the edition from Windows Pro to Enterprise, all during the first power-on. Forrester’s Total Economic Impact study, commissioned by Microsoft, put numbers on the shift: a composite organization moving to Microsoft 365 E3, Intune, and Autopilot saw a [197% return on investment over three years](https://tei.forrester.com/go/microsoft/365E3TeamsCopilot/index.html) and roughly 25,000 hours of endpoint deployment time saved. Those figures come from a vendor-commissioned model of a composite organization, so weigh them accordingly; the mechanism behind them is real: image maintenance disappears from your budget. ### Why Windows 11 Makes This the Moment to Move Windows 10 reached its end of support date in October 2025, so machines still running it now get no free security updates, and Autopilot is the migration mechanism that gets them onto Windows 11. You register each device once, and one profile then covers both fresh devices and reprovisioned ones. If you still have Windows 10 machines to move, you’re planning an Autopilot project whether you call it that or not. ## Prerequisites Autopilot ships as a capability inside subscriptions you likely already hold, with no separate product to license. To follow along hands-on, you need the following: * A Microsoft Entra ID tenant with [Microsoft Intune licensing](https://learn.microsoft.com/en-us/autopilot/requirements) for enrolling users; Microsoft 365 E3/E5, Business Premium, and F1/F3 all qualify. Without an Intune license on the signing-in user, enrollment hangs at the Enrollment Status Page (ESP), the progress screen that runs during provisioning. * Microsoft Entra ID P1 or P2 plus [automatic MDM enrollment](https://learn.microsoft.com/en-us/intune/device-enrollment/windows/enable-automatic-mdm) enabled, so devices that join Entra ID during OOBE also enroll in Intune. * A Global Administrator or Intune Administrator account for the portal work, plus a test user with an Intune license for the pilot sign-in. * Windows 11 Pro, Enterprise, or Education on target devices. Home editions don’t support Autopilot, and self-deploying mode requires a TPM 2.0 module. * Internet access from the device. A cloud-only join needs no VPN and no domain-controller line of sight; the hybrid path changes that. Portal paths follow the current Microsoft Intune admin center layout, and PowerShell commands run in an administrator PowerShell session on Windows 11; version-specific requirements are called out where they apply. ## Deciding the Deployment Path: Cloud Join, Hybrid Join, or Device Preparation Settle the join type before you create anything, because it narrows which provisioning mechanism you can use. How the device joins decides your profile settings; which provisioning mechanism you use decides your group rules. ### Cloud-Only Microsoft Entra Join The device joins Entra ID during OOBE and enrolls in Intune with no dependency on on-premises Active Directory. This is the path Microsoft designs for, and the one every step of the [user-driven Microsoft Entra join workflow](https://learn.microsoft.com/en-us/autopilot/tutorial/user-driven/azure-ad-join-workflow) assumes. Provisioning works over any internet connection, so a laptop can ship straight to a home office and enroll itself. Choose it unless a concrete dependency forces hybrid. ### Hybrid Microsoft Entra Join Hybrid join keeps the device a member of on-premises Active Directory while registering it in Entra ID, which matters when legacy domain-joined workflows or GPO-bound applications still rule. The cost is real: you must install the [Intune Connector for Active Directory](https://learn.microsoft.com/en-us/autopilot/windows-autopilot-hybrid) on a server that can reach a domain controller, and the device needs line of sight to that controller during provisioning, which remote users satisfy with an always-on VPN. Microsoft’s [ESP documentation](https://learn.microsoft.com/en-us/intune/device-enrollment/windows/setup-status-page) notes hybrid deployments take 40 minutes longer than the timeout you configure, because the connector must create the device record in Entra ID first. That tax plus the connector make hybrid the leading source of Autopilot failures, so treat hybrid join as a temporary state and plan the move to cloud-only join. The [GPO-to-Intune migration](https://adamtheautomator.com/gpo-intune-migration/) project is the work that lets you eventually leave hybrid behind. * * * _**Reality Check: If someone proposes hybrid join “just to keep GPOs working,” push back. Hybrid Autopilot needs a domain-joined connector server, line of sight to a domain controller during OOBE, and carries the highest failure rate of any Autopilot path. Move the GPOs that matter to Intune first, then deploy cloud-only.**_ * * * ### Windows Autopilot Device Preparation [Windows Autopilot device preparation](https://learn.microsoft.com/en-us/autopilot/device-preparation/overview) is a second provisioning experience for Windows 11, and it removes the two friction points of classic Autopilot: hardware hash registration and dynamic group lag. Its core mechanism is Enrollment Time Grouping: the device joins a pre-defined security group the moment the user authenticates, so assigned apps, scripts, and policies deploy immediately. The tradeoffs matter. Device preparation requires Windows 11 22H2 or 23H2 with the KB5035942 update, or 24H2 and later, per Microsoft’s [device preparation requirements](https://learn.microsoft.com/en-us/autopilot/device-preparation/requirements), and supports only cloud-only join, so you can’t use it if you need hybrid join. Classic Autopilot stays the right choice for hybrid join, Windows 10 holdovers, or OEM-registered fleets. Evaluate device preparation first for a greenfield cloud-only rollout; this guide walks classic Autopilot because it covers more environments. ## Registering Devices With Windows Autopilot Before a device can use Autopilot, it must be registered with the Windows Autopilot deployment service. Registration and enrollment are separate events: Microsoft’s [registration overview](https://learn.microsoft.com/en-us/autopilot/registration-overview) confirms a registered device already appears in Intune’s Windows Autopilot Devices list. That device becomes an enrolled Intune device, visible in the main Windows devices list, only after Autopilot runs on it for the first time. Registration tells the cloud which hardware belongs to your tenant so your profile is applied during OOBE. ### Registering Through an OEM or Partner The preferred path for new hardware is to have the OEM, reseller, or CSP [register devices before shipping](https://learn.microsoft.com/en-us/autopilot/oem-registration). You hand over your tenant ID, they upload the hardware identities, and boxes arrive already recognized. Confirm they appear under Windows Autopilot devices in Intune after delivery. * * * _**Warning: Autopilot registration marks a device as corporate-owned. Don’t upload hashes for personally owned machines or devices already enrolled as Microsoft Entra registered (workplace joined); Microsoft explicitly lists both as devices that shouldn’t be registered, and fixing it means deleting the device from Intune and Entra ID and starting over.**_ * * * ### Registering Existing Devices With PowerShell For machines already in your possession, or for lab testing, harvest the hash yourself. The [documented PowerShell method](https://learn.microsoft.com/en-us/autopilot/add-devices) runs in an administrator PowerShell session on the device: ```powershell [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 New-Item -Type Directory -Path "C:\HWID" Set-Location -Path "C:\HWID" $env:Path += ";C:\Program Files\WindowsPowerShell\Scripts" Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned Install-Script -Name Get-WindowsAutopilotInfo Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csv ``` The first six lines set TLS 1.2 for the Gallery download, create and enter a working folder, put the Gallery script path on `$env:Path`, relax the execution policy for this process only so the script can run without changing machine policy, and install Get-WindowsAutopilotInfo. The last command writes a CSV with the serial number, Windows product ID, and hardware hash. Hashes include timing details and change with every generation, so collect close to rollout and regenerate after a motherboard replacement. You can also upload directly with the `-Online` switch, which skips the CSV. ### Importing the CSV and Syncing Sign in to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), open **Devices > Windows > Enrollment > Windows Autopilot > Devices**, choose **Import**, point the picker at your CSV, and confirm. Each upload accepts up to 500 devices, per Microsoft’s [documented CSV device limit](https://learn.microsoft.com/en-us/autopilot/faq#is-there-a-limit-to-the-number-of-devices-that-can-be-listed-in-the-csv-file), and afterward you must select **Sync**, which you can run only once every 10 minutes, so batch uploads first. Refresh and watch for your machines with a Profile status of Unassigned, which changes only after a profile is assigned later in this guide. ## Creating the Autopilot Device Group The deployment profile, the Enrollment Status Page, and your app assignments all target device groups. Microsoft’s [device group tutorial](https://learn.microsoft.com/en-us/autopilot/tutorial/user-driven/azure-ad-join-device-group) recommends dynamic groups beyond a handful of test machines, since maintaining an assigned group by hand across hundreds of devices does not scale. ### Dynamic Device Group for One Pilot Device Create the group with the Microsoft Graph PowerShell SDK so the membership rule lives in source control and replays for every ring. Microsoft documents an exact `-eq` match on only two device attributes for dynamic-membership rules: `OrderID` (group tag) and `PurchaseOrderId`. A device’s ZTDId supports only the broader `-startsWith` match, so scoping a rule to a single pilot machine means giving that machine its own group tag. Open the pilot device’s entry under **Windows Autopilot devices** in Intune, edit its **Group tag** to a unique value, for example `PilotDevice001`, and select **Save**. ```powershell Connect-MgGraph -Scopes "Group.ReadWrite.All" New-MgGroup -DisplayName 'Autopilot Pilot Devices' ` -MailEnabled:$false ` -MailNickname 'autopilotpilot' ` -SecurityEnabled ` -GroupTypes 'DynamicMembership' ` -MembershipRule '(device.devicePhysicalIds -any (_ -eq "[OrderID]:PilotDevice001"))' ` -MembershipRuleProcessingState 'On' ``` `-GroupTypes 'DynamicMembership'` is what makes the rule evaluate at all; without it the group stays static and `-MembershipRule` is ignored. `-MembershipRuleProcessingState 'On'` starts evaluation immediately rather than leaving the rule paused, and `Group.ReadWrite.All` is the delegated permission the create call needs. Because only the pilot device carries the `PilotDevice001` tag, this rule matches exactly that one machine; the next section applies the same tagging mechanism at fleet scale. ### Group Tags for Fleet Scale For production, use group tags. A tag is a label assigned at registration, either by your OEM or with `-GroupTag "AutopilotPilot"` on the PowerShell script, and it appears in the device’s physical IDs with the prefix `[OrderID]:`. One dynamic rule then catches every tagged device: ```text (device.devicePhysicalIds -any (_ -eq "[OrderID]:AutopilotPilot")) ``` That pattern stages rollouts: register the first wave with an `AutopilotPilot` tag and point a pilot group at it, then later waves with `AutopilotRing1` and `AutopilotRing2` tags as you expand. Changing a device’s tag moves it to another group and profile. ## Creating and Assigning the Deployment Profile The deployment profile decides how the device behaves on first power-on: it sets the deployment mode and customizes the out-of-box experience (OOBE) users see. Create one under **Windows Autopilot > Deployment Profiles > Create Profile > Windows PC**, per the [profile configuration documentation](https://learn.microsoft.com/en-us/autopilot/profiles). The scripted equivalent is a `POST /deviceManagement/windowsAutopilotDeploymentProfiles` call through `Invoke-MgGraphRequest` with the `DeviceManagementServiceConfig.ReadWrite.All` scope; verify the result afterward with `Get-MgBetaDeviceManagementWindowsAutopilotDeploymentProfile`. The profile sits in the middle of a chain that starts at the factory image and ends at a managed desktop, as you can see below. ![Autopilot provisioning flow](https://adamtheautomator.com/wp-content/uploads/publisher/7e8cd17663bd87b40bc58cb4b6dc4b8b3ac2363af73f15ccc6d391aac657667a.webp) ### Out-of-Box Experience Settings On the **Out-of-box experience (OOBE)** page, pick **User-driven** for Deployment mode when a person signs in during setup, or **Self-deploying** for shared devices, kiosks, and digital signage; self-deploying authenticates with the TPM, so it fails on VMs and hardware without a real TPM 2.0. For a standard corporate laptop, configure the rest like this: | Setting | What it does | Recommendation | | --- | --- | --- | | Join to Microsoft Entra ID as | Chooses the directory the device joins during OOBE | Microsoft Entra joined, or Microsoft Entra hybrid joined, per your earlier decision | | Microsoft Software License Terms and Privacy settings | Control which consent screens appear during setup | Choose whether to show them; hiding privacy settings disables location services by default, so re-enable location through policy if an app needs it | | Hide change account options | Removes the consumer Microsoft account option from the company sign-in page | Hide, so users cannot switch to a consumer Microsoft account. This requires [company branding](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-customize-branding) in Entra ID | | User account type | Sets whether the enrolling user is a standard user or a local administrator | Standard is the security-correct default; the enrolling user joins local Administrators only when you choose Administrator | | Language (Region) and Automatically configure keyboard | Set the device language and keyboard layout during OOBE | Language selection happens before Wi-Fi is available, so these settings need a wired connection during OOBE | | Apply device name template | Auto-generates a device name during enrollment | Names like `LAP-%SERIAL%`, capped at 15 characters, with `%SERIAL%` and `%RAND:x%` macros supported | The OOBE page looks like this once every setting above is applied, as shown below. ![OOBE profile settings](https://adamtheautomator.com/wp-content/uploads/publisher/5cf15140f3493b023074c62e49fec3e551b118cebcf23337352b63c2aa0960ff.webp) ### Assigning the Profile and Reading Profile Status On the **Assignments** page, assign the profile to your device group with **Selected groups**. If a device falls into multiple profiles, the oldest created profile wins. If you enable **Convert all targeted devices to Autopilot** on the Basics page, every corporate device already enrolled in Intune inside the assigned groups registers for the Autopilot service automatically. Allow up to 48 hours for that registration, per Microsoft’s deployment profile documentation; disabling the setting later doesn’t unregister those devices. After assignment, return to the Windows Autopilot devices list and watch Profile status move from Unassigned to Assigning to Assigned, then confirm Date assigned is populated. Deploying before that date is set is the classic “I registered it, why did nothing happen” mistake: the profile had not reached the device. ## Configuring the Enrollment Status Page The ESP is the progress screen users watch while provisioning finishes, and it keeps the device off the desktop until every required app and profile finishes installing, per Microsoft’s [ESP overview](https://learn.microsoft.com/en-us/autopilot/enrollment-status). Configure it under **Devices > Enrollment > Windows Autopilot > Enrollment Status Page > Create**. The scripted equivalent is a `POST /deviceManagement/deviceEnrollmentConfigurations` call through `Invoke-MgGraphRequest` with an `@odata.type` of `#microsoft.graph.windows10EnrollmentCompletionPageConfiguration` and the `DeviceManagementServiceConfig.ReadWrite.All` scope; list the result afterward with `GET /deviceManagement/deviceEnrollmentConfigurations`. ### Core ESP Settings The settings that matter most for a first rollout, per the ESP profile documentation: | Setting | What it does | Recommendation | | --- | --- | --- | | Show app and profile configuration progress | Shows progress during setup | Yes | | Show an error when installation takes longer than specified number of minutes | Timeout per phase, 60 min default | 60 to 90 minutes while Office installs | | Block device use until all apps and profiles are installed | Blocks leaving the ESP early | Yes for the device phase | | Block device use until these required apps are installed | All, or a Selected blocking list | Selected, five or fewer apps | | Install Windows quality updates | Installs the monthly update in OOBE | Optional; adds time depending on update size, so measure it during your pilot | | Turn on log collection and diagnostics page for end users | Lets users export logs on failure | Yes | ### Choosing Blocking Apps and Timeout Math Every blocking-list app must finish before the user reaches the desktop, so each addition stretches provisioning and widens the timeout-failure window. Keep the list to essentials: the VPN client, your management agent, and one or two line-of-business apps the user cannot work without. Everything else installs in the background after the desktop appears. * * * _**Pro Tip: If Microsoft 365 Apps is on your blocking list, deploy it as a Win32 app. Microsoft documents that the built-in Microsoft 365 Apps app type can hang the ESP when the Office installer runs while another tracked Win32 app is installing.**_ * * * Match the timeout to what you block: with Office and a VPN client tracked, a 60-minute default can fail late on slow connections, forcing a full enrollment restart. Set 90 minutes for pilot runs, measure real provisioning time, then tune down. Also decide whether the ESP appears for every new sign-in or only during OOBE; on shared hardware, OOBE-only keeps later users out of a setup screen they don’t need. You’ll find the timeout, the blocking list, and the sign-in display setting together on the same page of the ESP profile, as shown below. ![ESP profile settings](https://adamtheautomator.com/wp-content/uploads/publisher/c918968cd50149791212dc6688ce7b61bf4d49f9502e3af7a723ec373da341f0.webp) ## Deploying Apps and Policies Ahead of First Sign-In The profile and ESP define how provisioning runs, but the apps and policies delivered during it come from your normal Intune assignments. Software assignment works the same as it always has, and Autopilot installs those apps during enrollment. Only apps assigned as **Required** to the device group or the enrolling user are candidates; available apps wait for the Company Portal. Only blocking-list apps are guaranteed to finish before the desktop appears; other required apps install in the background. Assign blocking apps to the device group where you can, because device-context installation completes during the device setup phase, before user apps begin. ### Packaging Apps for Reliable Provisioning Prefer Win32 apps with detection rules over line-of-business (LOB) installers for anything beyond a silent MSI. Win32 apps give you install commands, return-code handling, and detection logic, which is what an app needs to provably finish before the ESP marks it complete. Microsoft 365 Apps, your VPN, and agent software belong in this category, and Microsoft’s ESP guidance specifically [recommends Win32 packaging for Microsoft 365 Apps](https://learn.microsoft.com/en-us/intune/device-enrollment/windows/setup-status-page) over the built-in app type to avoid provisioning hangs. Assign security profiles, like BitLocker and Windows Defender, to the device group so they apply during the device phase, before the user signs in for the first time. Intune keeps applying assignments after enrollment, so heavy software rides along post-setup. When provisioning feels slow, start by shortening the blocking list before you blame the network. ## Deploying and Verifying a Windows 11 Autopilot Pilot Portal configuration means nothing until a real device walks the path, so run one machine through the full experience before announcing a rollout. This assumes the earlier steps are done in order, per the user-driven Microsoft Entra join workflow: enrollment configured, device registered, profile and ESP assigned, and Profile status showing Assigned. ### Running the First Deployment Reset the device to its out-of-box state, or unbox a fresh one, and power it on. First screens are language, region, and keyboard, then the network prompt; on a wired connection little interaction is needed. Once networked, the device contacts the Autopilot service, recognizes its hardware hash, and downloads your profile, which replaces consumer setup screens with your company sign-in page. Sign in with the test user’s Entra ID credentials, complete any MFA your Conditional Access policies demand, and the ESP takes over: the device joins Entra ID, enrolls in Intune, and moves through device setup and account setup while you watch the progress indicators. If you reset a device that already enrolled once, delete its record in Intune first, or the redeployment fails with the 0x80180014 error covered in the troubleshooting section. And if the sign-in page never appears and the device falls into consumer setup, the machine isn’t registered, its profile isn’t assigned, or Date assigned was empty when you started; every one of those is a portal-side fix. ### Verifying the Deployment Confirm each of the following before calling the pilot clean, even after the ESP completes: * The device appears in Intune under **Devices > Windows**, enrolled with your test user as primary user, and in Entra ID as Microsoft Entra joined with an enrollment date matching the pilot run. * The Windows Autopilot deployment status report, under **Devices > Monitor**, shows the expected result and keeps 30 days of history, per Microsoft’s [Intune reporting documentation](https://learn.microsoft.com/en-us/intune/device-management/reports/overview). * Blocking apps are installed, BitLocker reports encryption active, and the compliance policy marks the device compliant. Run the pilot on one laptop per vendor and model family before scaling. A golden image hid OEM firmware differences by shipping the same tested driver set to every model, and Autopilot doesn’t, so log provisioning time per model as your troubleshooting baseline. ### Reprovisioning Windows 10-Era Hardware Windows 10’s October 2025 end of support probably pushed you into a Windows 11 refresh, and Autopilot handles the existing half of that fleet. Devices already enrolled in Intune and registered through the Convert all targeted devices to Autopilot setting can be reprovisioned remotely with [Windows Autopilot Reset](https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset), which wipes personal files, apps, and settings while keeping Entra ID and Intune enrollment. For unregistered machines, export the hash from Settings and import it as shown earlier; the next reset enrolls the device in Intune. Roll the refresh out in rings, promoting devices by changing their group tag when each ring validates. ## Troubleshooting Common Autopilot Failures Most Autopilot failures show up in the error code before you open a log. The table maps the codes you’re most likely to see, drawn from Microsoft’s [known issues](https://learn.microsoft.com/en-us/autopilot/known-issues) and [troubleshooting documentation](https://learn.microsoft.com/en-us/autopilot/troubleshooting): | Error code | Typical scenario | Fix | | --- | --- | --- | | 0x800705B4 | Timeout during enrollment; common in self-deploying mode on a VM or non-TPM device | Confirm a real TPM 2.0; raise the ESP timeout for slow tracked apps | | 0x801c03ea | TPM attestation failed, so the device could not join Entra ID | Update TPM firmware from the OEM; verify the TPM is enabled | | 0x80180014 | Redeploying a device that already enrolled once | Delete the device record in Intune, then redeploy | | 0x80180005 | Pre-provisioning invoked while the profile disallows it | Enable pre-provisioning in the profile or stop invoking the flow | | 0xc1036501 | Multiple MDM configurations exist in Entra ID | Keep Microsoft Intune as the single MDM authority | | 0x80070774 | Hybrid failure during the ESP, domain mismatch | Reinstall the connector in the domain hosting the target devices | | 0x80180018 | Generic “Something went wrong” during enrollment | Assign a valid Intune license; check enrollment limits | | 0x81039024 | TPM attestation fails due to known TPM vulnerabilities | Install the OEM’s TPM firmware update | ### Where the Logs Hide The event logs carry the detail the error code leaves out. For registration and join issues, check **Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin**. The Intune Connector for Active Directory logs under **Microsoft > Intune > ODJConnectorService**, and provisioning events land in the **DeviceManagement-Enterprise-Diagnostics-Provider** log. The [ESP setup documentation](https://learn.microsoft.com/en-us/intune/device-enrollment/windows/setup-status-page) also flags an ESP stuck on “Identifying” when the signed-in user has no Intune license; if you enabled log collection in the ESP profile, the failed device can export diagnostics from the error screen. ### Diagnosing the “Device Did Nothing” Complaint The most common report carries no error code at all: the device boots straight into consumer setup. Work the chain in order: is the device listed under Windows Autopilot devices, does Profile status show Assigned with a Date assigned, and was the hash collected on this exact hardware state, since a motherboard replacement invalidates it? If all three pass, check the User Device Registration event log. In most cases the device was never registered, or the profile assignment hadn’t finished when the box was powered on. ## Frequently Asked Questions Can I use Autopilot for Windows 11 devices my organization already owns? Yes. Existing hardware registers through the same hardware-hash import used for new devices, from the PowerShell script or Settings, so you can deploy Windows 11 with Autopilot on machines you already own. Windows 10-era machines headed to Windows 11 can register first and then reset, or use Autopilot Reset if already Intune-managed. What is the difference between classic Windows Autopilot and Autopilot device preparation? Classic Autopilot registers hardware by hash and targets devices through dynamic groups, while [Windows Autopilot device preparation](https://learn.microsoft.com/en-us/autopilot/device-preparation/overview) uses Enrollment Time Grouping to add the device to a security group at sign-in and skips the hash requirement. Device preparation is Windows 11 only and supports cloud-only join, so if you need hybrid join, you must stay on classic Autopilot. Does Windows Autopilot require a VPN during deployment? Only on the hybrid path. Cloud-only join needs plain internet access. Hybrid join requires the Intune Connector for Active Directory and line of sight to a domain controller during OOBE, which remote users typically satisfy with an always-on VPN. Which license does the person unboxing the device need? An Intune license on the enrolling user is mandatory, and the tenant needs Microsoft Entra ID P1 or P2 for automatic enrollment configuration. Microsoft 365 Business Premium is the usual SMB answer because it bundles both. ## Next Steps The pilot device is running, so the numbers it produces decide how fast the rollout widens. Measure provisioning time on every new hardware model before mass deployment, since a model that runs past the ESP timeout fails silently for every user in that ring. Review the deployment status report weekly for the first month, while the rollout is still small enough to fix quickly. Then promote each ring by changing its group tag from AutopilotPilot to AutopilotRing1. Related: [Migrate Group Policy to Intune Without Breaking Endpoints](https://adamtheautomator.com/gpo-intune-migration/) and [How to Protect Your Endpoints with Microsoft Intune](https://adamtheautomator.com/intune/) walk the two projects that make a cloud-only Autopilot rollout possible: policy migration off the domain, and the Intune baseline waiting for your devices after enrollment. Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Fdeploy-windows-11-with-autopilot-and-eliminate-ima%2F&text=Deploy%20Windows%2011%20with%20Autopilot%20and%20Eliminate%20Imaging)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Fdeploy-windows-11-with-autopilot-and-eliminate-ima%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Fdeploy-windows-11-with-autopilot-and-eliminate-ima%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/2026/06/featured_image-22.png) ### [Implement Workload Identity in AKS](/implement-workload-identity-aks/) A deep dive into replacing vulnerable service account credentials with Microsoft Entra Workload Identity in Azure Kubernetes Service (AKS). The post covers federated identity configuration, managed ![](https://adamtheautomator.com/wp-content/uploads/2026/06/26997-implementing-workload-identity-aks-codex.webp) ### [Implementing Workload Identity in AKS](/implementing-workload-identity-aks/) Implement Microsoft Entra Workload ID in AKS to replace static pod credentials with federated identity and managed identity access. ![](https://adamtheautomator.com/wp-content/uploads/2026/09/featured_image-1.webp) ### [Bicep: Never Hand-Write Azure ARM JSON Again](/azure-bicep-vs-arm-templates/) Learn how Bicep simplifies Azure infrastructure deployment with domain-specific language, dependency inference, and reusable modules for cleaner IaC. ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)