Windows Deployment: Autopilot, MDT, SCCM, and Zero-Touch Setup
Why Windows Deployment Breaks , And Why It's Not Your Fault
You've got thirty new laptops sitting in boxes. IT leadership wants them imaged and deployed by end of week. You fire up your deployment process , and something breaks. Maybe the Windows Autopilot profile never downloads. Maybe SCCM's task sequence errors out at driver injection. Maybe MDT hangs at "Applying Operating System Image" and just sits there, frozen, mocking you. I've been in that exact room, sweating through a deployment deadline, and I know how isolating it feels when Microsoft's error messages say almost nothing useful.
Here's what's actually going on. Windows deployment isn't a single product, it's a spectrum of methods that Microsoft has built up over years, layered on top of each other. You've got modern deployment (Windows Autopilot and in-place upgrades), dynamic deployment (Subscription Activation, Microsoft Entra ID with MDM, provisioning packages), and traditional deployment (bare metal, refresh, replace using Configuration Manager). Each category has different prerequisites, different failure modes, and different places where things silently fall apart.
The biggest source of confusion? Organizations try to mix methods without realizing the constraints. You can't use a custom WIM image with an in-place upgrade, Windows Setup will reject it because it can't reconcile application conflicts between the old OS and the new image. A common example: an organization has Contoso Timecard 1.0 running on Windows 10 and tries to upgrade with a custom image containing Timecard 3.0. Setup fails, no clear error, everyone is confused. The documentation is clear on this, but most engineers only find that note after hours of troubleshooting.
Another huge category of Windows deployment failures comes from BIOS/UEFI mismatches. Devices that boot in legacy BIOS mode but are UEFI-capable will fail specific deployment paths unless you handle the MBR-to-GPT conversion correctly, and in the wrong order, you can brick the boot process entirely. Windows 11 makes this worse because it requires UEFI and does not support legacy BIOS at all, unlike Windows 10 which was more forgiving.
And then there's the network layer. Zero-touch deployments depend heavily on DNS, DHCP, PKI infrastructure, and cloud service reachability. A blocked endpoint, an expired certificate, or a missing DHCP scope option can silently kill Autopilot enrollment before a single user ever touches the keyboard.
This guide walks you through every major Windows deployment scenario, from Autopilot to SCCM task sequences to zero-touch MDM enrollment, with the exact steps, error codes, and registry paths that actually fix things. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into logs and Group Policy, there's one check that resolves a surprisingly high percentage of Windows deployment failures: verify your deployment scenario prerequisites are actually met. This sounds obvious, but Microsoft's deployment tools will often proceed halfway through a task sequence or enrollment before failing, leaving you debugging symptoms rather than the root cause.
For Windows Autopilot, the device must be running a currently supported version of Windows before Autopilot can run. If you're trying to Autopilot a machine running Windows 10 21H1 (which reached end of service), the process will fail at profile download. Check the device's current OS build: press Win + R, type winver, hit Enter. If that build is out of support, do an in-place upgrade first, then re-run Autopilot enrollment.
For in-place upgrades via Configuration Manager, the fastest diagnostic is to check the setupact.log file located at C:\$WINDOWS.~BT\Sources\Panther\setupact.log. This log contains the actual Setup.exe output and will tell you specifically what blocked the upgrade, incompatible driver, application conflict, disk space issue, or TPM check failure. Most generic "upgrade failed" messages in SCCM trace back to a specific line in this log.
For MDT or SCCM bare-metal deployments, the single most common silent failure is a missing or misconfigured network boot (PXE) response. Open the DHCP console, go to your scope options, and confirm Option 066 (Boot Server Host Name) and Option 067 (Bootfile Name) are set correctly. If you're running SCCM distribution points, also check that the WDS (Windows Deployment Services) service is running on the DP and that the firewall allows UDP 67, 68, 69, and 4011.
Run this quick PowerShell one-liner on the target machine to export its hardware hash for Autopilot registration if manual upload is needed:
Install-Script -Name Get-WindowsAutoPilotInfo -Force
Get-WindowsAutoPilotInfo -OutputFile C:\AutopilotHWID.csvUpload that CSV to Intune > Devices > Enroll devices > Windows enrollment > Devices. This bypasses OEM registration delays and gets your device into the Autopilot pool within minutes.
eventvwr.msc and look under Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider. The event IDs there, particularly 3701, 3710, and 3800, will point directly to whether the failure is profile delivery, AAD join, or MDM enrollment.
The number one mistake I see IT teams make is starting deployment tasks before locking in which scenario they're actually using. Microsoft structures Windows deployment into three distinct categories, and mixing them creates hard-to-diagnose failures. Take five minutes here and save yourself hours later.
Modern methods are what you want for most new deployments in 2026. Windows Autopilot is the flagship, it customizes the Out-of-Box Experience (OOBE) so end users receive a fully configured device without any IT imaging infrastructure. There are no WIM images to maintain, no driver packs to inject, and no imaging servers to babysit. The device ships directly from the OEM or distributor, the user powers it on, signs in with their work credentials, and Autopilot applies the profile from Intune. It's genuinely elegant when it works.
In-place upgrades are the right call when you're modernizing a fleet of existing Windows 10 machines to Windows 11. The Windows Setup engine (Setup.exe) handles everything automatically, it migrates apps, settings, user data, and drivers. Nothing gets wiped. You control the rollout through Configuration Manager task sequences, which lets you stagger deployments across OU boundaries and roll back cleanly if something breaks. Rollback data is stored in the Windows.old folder automatically.
Traditional bare-metal deployments, where you PXE boot a device, wipe the disk, and lay down a fresh image, are still valid for specific use cases: kiosk machines, lab environments, and devices that need a completely clean OS with no user state to preserve. These use Configuration Manager OSD (Operating System Deployment) task sequences with WIM images distributed to DPs.
Document your choice. Create a short decision record: which scenario, which devices, which OS version target, and who owns it. This prevents the mid-deployment pivot that causes most catastrophic failures. Once you've picked your scenario, verify the starting OS on all target devices meets the minimum version requirement, especially for Autopilot and Subscription Activation, which both require a currently supported Windows version as the starting point.
Autopilot configuration lives entirely in Microsoft Intune, and getting the profile right before any devices try to enroll is non-negotiable. Here's the exact path: sign in to the Microsoft Intune admin center at intune.microsoft.com, go to Devices > Windows > Windows enrollment > Deployment profiles, and click Create profile > Windows PC.
The settings that cause the most deployment failures when misconfigured:
- Deployment mode: Choose "User-driven" for standard employee devices. "Self-deploying" is for kiosks and shared devices, it uses the TPM chip for authentication and has strict hardware requirements (TPM 2.0 with EK certificate).
- Join to Azure AD as: Set to "Azure AD joined" for cloud-native deployments. If you need hybrid Azure AD join (domain-joined + Azure AD registered), select "Hybrid Azure AD joined", but note this requires the Intune Connector for Active Directory installed on a domain-joined server and has significantly more prerequisites.
- Automatically configure keyboard: Set this to match your region. When it's left at default and doesn't match the device locale, users get stuck at the keyboard selection screen despite Autopilot supposedly skipping OOBE steps.
After creating the profile, assign it to a device group. The device must be in this group before it attempts enrollment, or the profile won't be delivered. To verify profile assignment is working, run this from an admin PowerShell session after the device is registered:
$AutopilotProfile = Invoke-RestMethod -Uri "https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeviceIdentities" -Headers $headers
$AutopilotProfile | Select-Object id, deploymentProfileAssignmentStatusLook for assignedInSync as the status. If you see notAssigned, the device isn't in the target group. If you see failed, check the Autopilot deployment profile assignment logs under Intune > Devices > Monitor > Autopilot deployments.
This step catches a lot of organizations off guard. If your fleet has older machines that boot in legacy BIOS mode, you cannot upgrade them directly to Windows 11. Full stop. Windows 11 only supports UEFI-capable systems, it doesn't support legacy BIOS or MBR disk layouts at all. This is a hard requirement, not a soft recommendation.
The correct sequence, per Microsoft's official guidance, is a two-step process. First, upgrade the device to Windows 10 while keeping legacy BIOS mode. Windows 10 works fine on legacy BIOS, so this upgrade succeeds cleanly. Second, convert the disk from MBR to GPT using the MBR2GPT tool, then switch the firmware from legacy BIOS to UEFI mode.
Here's how to run the MBR2GPT conversion. Open an elevated command prompt (Run as Administrator) and first validate the disk is eligible:
MBR2GPT /validate /disk:0 /allowFullOSIf validation passes with "Validation completed successfully," run the actual conversion:
MBR2GPT /convert /disk:0 /allowFullOSAfter conversion completes, reboot into BIOS/UEFI firmware settings (usually F2, F10, Del, or Esc at POST, varies by manufacturer), find the Boot Mode setting, and change it from "Legacy" or "CSM" to "UEFI." Save and exit. The machine should boot Windows 10 normally from the now-GPT disk in UEFI mode.
Once you're booted in UEFI mode on Windows 10, you can now enable Secure Boot in firmware settings (highly recommended, it's required for Windows 11 certification). After that, your in-place upgrade path to Windows 11 is open. Without this sequence, every Windows 11 upgrade attempt will fail at compatibility check with error 0xC1900208 or a generic "This PC can't run Windows 11" message that doesn't explain why.
If you're running SCCM, you can automate the MBR2GPT conversion as a task sequence step using a Run Command Line step with the MBR2GPT syntax above, followed by a restart and a BIOS configuration step using your OEM's firmware utility.
Deploying Windows is only half the job. Once devices are running, you need to control how and when they receive feature updates. Without proper Windows Update client policies, Windows Update will install feature updates on its own schedule, which means you could have half your fleet on Windows 11 23H2 and the other half on 24H2, with no control over when the transition happened. In enterprise environments, that's a compliance and support nightmare.
Windows Update client policies are configured through either Group Policy (for on-premises managed devices) or Intune Update Rings (for cloud-managed devices). For most modern deployments using Autopilot and Intune, Update Rings are the right tool.
In Intune, go to Devices > Windows > Update rings for Windows 10 and later and create a new ring. The critical settings:
- Feature update deferral period: Set this to at least 30 days for your pilot ring, 60–90 days for production. This gives Microsoft time to patch the initial update bugs before your fleet gets it.
- Quality update deferral period: 7 days is a reasonable minimum. Zero-day deferral means security patches hit immediately, which is fine for security-sensitive environments but can cause compatibility breaks.
- Automatic update behavior: Set to "Auto install and restart at scheduled time" for desktops, "Notify for download and auto install" for endpoints where users have sensitive work in progress.
For Group Policy environments, the equivalent settings are under Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Services (if using WSUS) or Manage end user experience for client-side behavior. The Group Policy path for deferral is Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business > Select when Preview Builds and Feature Updates are received.
After policy is applied, verify it landed on a test device by running:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" | Select-Object DeferFeatureUpdates, DeferFeatureUpdatesPeriodInDays, DeferQualityUpdates, DeferQualityUpdatesPeriodInDaysWhen Autopilot isn't the right fit, high-security environments, offline deployments, complex driver requirements, Configuration Manager (SCCM/MECM) OSD task sequences are your path. A well-built task sequence handles everything: PXE boot, disk formatting, image application, driver injection, application installation, and domain join, all without any manual intervention. That's the zero-touch promise of traditional deployment done right.
Here's the basic architecture you need in place before any task sequence will run successfully:
- Management Point (MP): Handles client policy and status messages. Needs HTTP or HTTPS on port 80/443.
- Distribution Point (DP): Stores the boot images, OS images, driver packages, and application content. WDS must be running on the DP if you're using PXE.
- State Migration Point (SMP): Only needed for Refresh scenarios where you're saving and restoring user state (USMT).
The most common task sequence failure point is content not making it to the DP before deployment starts. Always check DP content status before kicking off OSD: in the SCCM console go to Monitoring > Distribution Status > Content Status, find your OS image, and confirm it shows Success on all target DPs. If you see "In Progress" or "Failed," distribution hasn't completed, running a task sequence against a DP with incomplete content produces cryptic WinPE errors that look hardware-related but aren't.
During a running task sequence, all logs write to X:\Windows\Temp\SMSTSLog\smsts.log in WinPE, then move to C:\Windows\CCM\Logs\smsts.log after the OS partition is formatted. Tail this file in real time if you have a second machine available:
Get-Content -Path "C:\Windows\CCM\Logs\smsts.log" -Wait -Tail 50Look for lines containing Failed or error codes starting with 0x. The error 0x80070070 means insufficient disk space. Error 0x80004005 is a general access denied, usually a service account permission issue on the network share. Error 0x00000057 (invalid parameter) in the "Apply Driver Package" step almost always means a driver package targeting mismatch: the task sequence is trying to apply an AMD driver pack to an Intel machine, or vice versa. Check your driver package WMI query conditions.
Advanced Troubleshooting: When the Standard Fixes Don't Work
Sometimes you've done everything right and deployment still fails in a way that doesn't fit any obvious pattern. Here's where to go deeper.
Event Viewer Analysis for Autopilot Failures
The best Autopilot diagnostic logs are not in the obvious places. Open Event Viewer (eventvwr.msc) and navigate to Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Admin. Event ID 3701 indicates a profile download failure, usually caused by the device not being registered in Autopilot or a network issue blocking access to ztd.dds.microsoft.com. Event ID 3800 indicates an MDM enrollment failure after AAD join succeeded, this is often a licensing issue (the user needs an Intune license assigned) or an enrollment restriction blocking the device platform. Event ID 3710 is an AAD join failure, which usually means the device can't reach login.microsoftonline.com, check proxy and firewall rules.
Registry-Level Autopilot Diagnostics
After a failed Autopilot enrollment, the device stores state in the registry at:
HKLM:\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}Look at the EnrollmentState DWORD value. A value of 1 means enrolled successfully. A value of 6 means enrollment failed. The LastError value gives you the specific failure code to search against Microsoft's MDM enrollment error codes documentation.
Group Policy Conflicts with Windows Update
In domain-joined environments, conflicting Group Policy Objects (GPOs) targeting the same Windows Update settings from different OUs cause unpredictable update behavior. Two GPOs fighting over the deferral period setting don't average out, whichever one wins the processing order wins completely. Run gpresult /h C:\gp_report.html on a affected machine and open the HTML report. Look for "Winning GPO" under each Windows Update policy setting. If you see a GPO you don't recognize winning, trace it back with Get-GPO -Name "GPO Name" in PowerShell and check its link order and enforcement status.
Microsoft Entra ID / MDM Join Failures
For dynamic deployment scenarios using Microsoft Entra ID (formerly Azure AD) with MDM auto-enrollment, the most common failure is the MDM auto-enrollment not triggering after AAD join. This is almost always caused by missing or misconfigured MDM terms of use URLs in Entra ID. In the Entra admin center, go to Mobility (MDM and MAM) > Microsoft Intune and verify the MDM User Scope is set to "All" or includes the target group. The MDM Discovery URL should be https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc, if this is blank or wrong, AAD join will succeed but MDM enrollment silently won't happen.
Provisioning Packages for MDM-Free Deployments
When you need to configure devices without MDM infrastructure, branch offices with no reliable cloud connectivity, for example, provisioning packages built with Windows Imaging and Configuration Designer (Windows ICD) are the answer. Packages are applied at OOBE or post-deployment and can configure Wi-Fi, certificates, policies, and applications. A common failure here is package signing: unsigned packages require enabling the "AllowUnsigned" registry key, while signed packages require the signing certificate to be trusted by the device. If a PPKG silently does nothing after application, check Event Viewer under Applications and Services Logs > Microsoft > Windows > Provisioning-Diagnostics-Provider for error codes.
If you're seeing persistent Autopilot failures with Event ID 3701 after confirming device registration, network access, and licensing are all correct, there may be a backend issue with the Autopilot service or a tenant-specific configuration problem that requires Microsoft to investigate on their end. Similarly, if SCCM OSD task sequences fail consistently with error 0x80070002 (file not found) after confirming all content is distributed, there may be a WMI corruption issue on the management point that requires escalation. For these situations, open a support case at Microsoft Support and include your smsts.log, DiagLogs bundle from Autopilot, and tenant ID. Cases with logs attached move significantly faster than those without.
Prevention & Best Practices for Windows Deployment
The best Windows deployment is the one that doesn't require emergency troubleshooting at 2am. These practices come from managing deployments at scale, some learned the hard way.
Always run a pilot ring first. Before you deploy any new OS version or update configuration to production, run it on 5–10% of devices for two weeks. This catches application compatibility breaks, driver failures, and policy conflicts in an environment where failure doesn't mean hundreds of users are down. Microsoft's own guidance for feature update deployment plans specifically calls for pilot rings before broad deployment, and this step saves organizations enormous amounts of incident response time.
Maintain your hardware hash database. For Autopilot deployments, keep an up-to-date record of every device's hardware hash, serial number, and Autopilot profile assignment. When a device fails to enroll or gets reset, having this data means you can re-register and re-assign in under five minutes instead of tracking down procurement records. The CSV export from Get-WindowsAutoPilotInfo is a perfect source for this.
Stage your content before your deployment window. For SCCM OSD deployments, distribute all content, boot images, OS images, driver packages, application packages, to all target DPs at least 24 hours before your maintenance window. Content replication takes time and doesn't always succeed on the first attempt. Trying to start an OSD deployment while content is still replicating is one of the most reliably bad decisions in enterprise IT.
Document your firmware settings. For each hardware model in your fleet, document the exact BIOS/UEFI settings required, secure boot state, TPM version and status, boot order, CSM/legacy mode status. When a deployment fails on a specific model and only that model, firmware settings are almost always the reason. Having a per-model "expected firmware state" document turns a two-hour debug session into a five-minute fix.
Monitor Windows Update compliance continuously. Don't wait for deployment to check if policies landed. Use Windows Update for Business Reports in Intune (or SCCM's built-in Software Update compliance reports) to track update status across your fleet weekly. When you catch a device that's fallen 90 days behind on quality updates before it becomes 180 days behind, remediation is a conversation. When you catch it at 180 days, it's an incident.
- Run
MBR2GPT /validateagainst your entire fleet before any Windows 11 deployment project begins, find your BIOS-only machines early, not mid-project. - Create a dedicated Autopilot staging Intune group so new devices can be validated before moving to their permanent assignment group.
- Set Windows Update deferral policies before devices enroll, not after, policies applied retroactively sometimes require a device sync cycle before they take effect, creating a window of unprotected update exposure.
- Keep a copy of the Windows ADK version that matches each OS you support, driver servicing, WinPE customization, and DISM operations all have ADK version dependencies that cause silent failures when mismatched.
Frequently Asked Questions
What's the difference between Windows Autopilot and MDT for deploying new PCs?
Autopilot is cloud-driven and requires no on-premises imaging infrastructure, the device connects to the internet during OOBE, downloads its configuration profile from Intune, and configures itself. MDT (Microsoft Deployment Toolkit) is an on-premises tool that requires a deployment share, WIM images, and network access to a local server. Autopilot is the modern approach Microsoft recommends for most new deployments in 2026; MDT is still valid for environments with complex driver requirements, offline deployments, or legacy application stacks that need custom WIM images. They can also be used together, MDT can deploy a base image that Autopilot then configures post-deployment.
Can I use a custom WIM image with an in-place upgrade to Windows 11?
No, you cannot use custom images with in-place upgrades, and this is a hard limitation of the Windows Setup engine. The upgrade process uses the standard Windows installation media (Install.wim) and cannot handle conflicts between applications in the old OS and applications embedded in a custom image. For example, if your custom WIM has a specific version of a business application pre-installed that conflicts with the version already running on the device, Setup has no way to resolve that and will fail. If you need custom applications, install them via SCCM application deployment or Intune apps after the upgrade completes.
My Autopilot device is stuck at "Setting up your device", how do I fix it?
Press Shift + F10 during OOBE to get a command prompt, then run eventvwr.msc and check Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider. Event ID 3701 means the Autopilot profile didn't download, verify the device is registered in Intune and that the network can reach ztd.dds.microsoft.com. Event ID 3800 means MDM enrollment failed after AAD join, check that the user has an Intune license assigned. Event ID 3710 is an AAD join failure, almost always a firewall or proxy blocking login.microsoftonline.com. Fix the root cause, then run dsregcmd /leave and restart OOBE to retry.
What are Windows Update client policies and do I need them if I use Intune?
Windows Update client policies are settings that control how Windows Update behaves on a device, when to download updates, how long to defer feature updates, whether users can pause updates, and how restart behavior is managed. If you manage devices with Intune, you configure these through Update Rings for Windows 10 and later rather than Group Policy. You absolutely still need them even with Intune, without Update Rings configured, devices update on Microsoft's default schedule, which means feature updates can install whenever Microsoft releases them, not when your IT team has tested them. Update Rings give you the deferral periods and maintenance windows that make enterprise update management predictable.
How do I convert a machine from MBR to GPT without losing data for a Windows 11 upgrade?
Use the MBR2GPT tool built into Windows 10, it converts the disk in-place without wiping data, which is what makes it safe for pre-upgrade use. Run MBR2GPT /validate /disk:0 /allowFullOS first to confirm the disk is eligible (must have fewer than four primary partitions and enough space for GPT metadata). If validation passes, run MBR2GPT /convert /disk:0 /allowFullOS. After conversion, enter your BIOS/UEFI firmware settings and switch the boot mode from Legacy/CSM to UEFI, then save and exit. The machine boots normally, and you can now proceed with the Windows 11 in-place upgrade. Do not skip the validation step, converting an ineligible disk can cause boot failures.
What's the difference between a Refresh and a Replace deployment in SCCM?
Both use SCCM OSD task sequences but handle user state differently. A Refresh (also called wipe-and-load) is performed on the same physical device: user state is captured to a State Migration Point using USMT, the disk is wiped, a fresh OS image is applied, and user state is restored. The user keeps their files, settings, and browser favorites but gets a clean OS. A Replace is used when you're retiring an old device and deploying a new one: user state is captured from the old machine, the new machine is imaged fresh, and user state is restored to the new hardware. The old machine is then decommissioned. Both scenarios require a State Migration Point in your SCCM hierarchy and a USMT package distributed to your DPs.