Fix Windows Deployment Errors
Why Windows Deployment Fails , And Why the Errors Don't Help
Windows deployment errors have a special talent for being spectacularly unhelpful. You kick off what should be a routine upgrade or fresh image deployment, walk away for coffee, and come back to a machine stuck at 32% with error code 0xC1900101 or a cryptic "Setup cannot continue" message that tells you absolutely nothing about what actually went wrong.
I've seen this exact situation on dozens of machines , sometimes it's a driver conflict, sometimes it's a firmware setting that hasn't been touched since 2014, and sometimes it's something as deceptively simple as the wrong deployment scenario being used for the hardware in front of you.
Here's the thing most guides won't tell you: Windows deployment isn't one thing. Microsoft has three distinct categories of deployment methods, modern, dynamic, and traditional, and picking the wrong one for your situation is the single most common reason deployments fail before they even get going. Using Windows Autopilot on a machine that can't reach the internet during OOBE? That's going to fail. Trying to run a bare metal PXE deployment without the right WinPE boot image configured? Same result. The method has to match the scenario.
The most frequent pain points I see across enterprise IT shops and home users alike include:
- In-place upgrade failures, the machine rolls back silently, and you're left wondering why Windows 11 still shows Windows 10
- Windows Autopilot provisioning timeouts, devices stall at the enrollment status page with no obvious error
- BIOS/UEFI firmware conflicts, especially on older machines that need to move from legacy BIOS to UEFI before upgrading beyond Windows 10
- Windows Update client policy misconfigurations, managed devices not receiving updates because Group Policy or Intune MDM policies are fighting each other
- PXE boot failures, bare metal deployments that won't find the WDS server, often a DHCP scope option issue
- Task sequence errors in Configuration Manager, usually surface as cryptic TS step failures with exit codes like
0x80070005
Microsoft's deployment documentation is genuinely good, but it's written for architects planning from scratch, not for the IT admin at 4:30pm on a Friday trying to figure out why 40 machines just failed their in-place upgrade. This guide bridges that gap. Every fix here is grounded in the official Windows deployment documentation, translated into the exact steps you need right now.
Browse all Microsoft fix guides: Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your Windows deployment just failed and you're not sure where to start, this is your first move: verify you're using the right deployment scenario for your hardware and your starting OS version.
Microsoft is explicit about this in their official documentation, Windows Autopilot and Subscription Activation both require that the beginning OS is a currently supported version of Windows. If you're starting from Windows 7, Windows 8.1, or an end-of-life build of Windows 10, those modern deployment paths are off the table.
Here's the quick decision tree that resolves about 60% of the deployment failures I see:
- Existing device, needs upgrade? Use in-place upgrade via Windows Setup (
setup.exe). Don't touch custom images, the in-place process can't handle conflicts between old and new app versions in the image, and it doesn't need them. - New device, corporate enrollment? Windows Autopilot is your path. Zero images, zero driver injection, and end users can complete it themselves without IT involvement.
- New or wiped device, no cloud MDM? Bare metal deployment over PXE with Configuration Manager is the right call.
- Need to swap old hardware for new and preserve user state? Use the Replace scenario with USMT to capture the user state from the old device and restore it to the new one.
Once you've confirmed you're on the right deployment path, run the Windows 11 compatibility check if upgrading. Open PowerShell as administrator and run:
Get-AppxPackage -Name Microsoft.WindowsPC* | Select Name, VersionIf PC Health Check is installed it will tell you exactly which hardware requirement the machine is failing. TPM 2.0 and Secure Boot are the two most frequent blockers for Windows 11 deployment, and both are fixable in UEFI firmware settings on most modern machines.
C:\$WINDOWS.~BT\Sources\Panther\setuperr.log file. That log is worth more than 30 minutes of guessing.
Skipping this step is the number-one cause of failed upgrades. Windows 11 has non-negotiable hardware requirements, TPM 2.0, Secure Boot capability, a supported CPU, and at least 4GB RAM with 64GB storage. Unlike Windows 10, Windows 11 does not support legacy BIOS systems or MBR disk layouts at all. This is a hard line, not a suggestion.
Here's how to check programmatically across your fleet. Open PowerShell as administrator:
# Check TPM status
Get-Tpm
# Check Secure Boot status
Confirm-SecureBootUEFI
# Check UEFI firmware type (should return UEFI, not BIOS)
$env:firmware_typeIf Get-Tpm returns TpmPresent: False, the TPM module either doesn't exist or isn't enabled in firmware. Go into UEFI settings (typically F2 or Del at POST) and look for "TPM", "PTT" (Intel Platform Trust Technology), or "fTPM" (AMD firmware TPM) under the Security tab. Enable it, save, and reboot.
If Confirm-SecureBootUEFI throws an exception or returns False, Secure Boot is either disabled or the machine is booting in legacy BIOS mode. You'll need to convert the disk before you can enable it, covered in Step 2.
If the machine has a supported CPU but still fails the PC Health Check, verify that the CPU is on Microsoft's official supported processor list. Some early-generation Intel 8th and 9th series chips are excluded despite being otherwise capable hardware. In that case, in-place upgrade is blocked for the organization deployment path, but the Refresh scenario (wipe and load with a supported image) is still available.
When everything checks out, you should see TpmPresent: True, TpmReady: True, and Secure Boot returning True. That's your green light to proceed.
This is the step that trips up the most people. You have a machine that's technically capable of UEFI but has been running in legacy BIOS mode for years. The disk is MBR-formatted. Windows 11 won't install on it. Here's exactly what to do, and the order matters.
Microsoft's official guidance is clear on the sequence: first upgrade to Windows 10 while maintaining legacy BIOS mode (Windows 10 runs fine on MBR/legacy BIOS), then convert the disk, then configure the firmware. Don't try to flip to UEFI before the conversion, you'll brick the boot.
After you're running Windows 10, open an elevated Command Prompt and validate the disk first:
mbr2gpt /validate /disk:0If validation passes with "Validation completed successfully," run the actual conversion:
mbr2gpt /convert /disk:0This converts the disk layout from MBR to GPT without touching your data. The tool also updates the boot configuration data to support UEFI. Once that completes successfully, reboot into your UEFI firmware settings and:
- Change the boot mode from Legacy/CSM to UEFI
- Enable Secure Boot
- Set the boot device to the GPT partition on your drive
Save and exit. The machine should boot normally into Windows 10 in UEFI mode. Verify with $env:firmware_type in PowerShell, it should now return UEFI. At that point, your in-place upgrade to Windows 11 can proceed normally.
One thing: if mbr2gpt /validate fails with error code 3, the disk has more than 3 primary partitions or has a non-standard partition layout. That's the recovery partition situation, you may need to temporarily remove or consolidate partitions before conversion. Event Viewer under Windows Logs > Application will log the specific reason for the failure.
In-place upgrade is the officially recommended path for existing Windows devices, and for good reason, it automatically preserves all data, settings, applications, and drivers. You don't need to reinstall anything. The tradeoff is that it's more sensitive to conflicts than a clean install.
For enterprise deployments, you'll want to automate this through Configuration Manager with a task sequence rather than running setup manually. But for a single machine or testing, mount the Windows 11 ISO, open an elevated Command Prompt, and run:
setup.exe /auto upgrade /DynamicUpdate disable /Compat IgnoreWarningThe /DynamicUpdate disable flag prevents setup from pulling updated drivers during the upgrade, useful if you suspect a driver is causing the failure. The /Compat IgnoreWarning flag lets setup proceed past soft compatibility warnings (not hard blocks).
If the upgrade rolls back automatically, don't panic. Windows Setup designed it that way, it's a safety feature. Your machine is exactly where it was before you started. Now go find out why. Open File Explorer and navigate to:
C:\$WINDOWS.~BT\Sources\Panther\Open setuperr.log in Notepad. Look for lines starting with Error. Common error codes you'll see here:
0xC1900101, driver compatibility failure. Check Device Manager for any yellow-exclamation drivers first.0x800F0923, a driver or application isn't compatible. Setup will usually name the specific driver in the log.0x8007042B, setup failed during the second boot phase. Often a filesystem or permission issue.
After addressing the specific error, re-run setup. If you used Configuration Manager for the upgrade, check the task sequence status in the Monitoring workspace, failed steps show the exact exit code that caused the failure.
Windows Autopilot is the modern deployment path for new devices, no images, no drivers to inject, no PXE infrastructure to maintain. When it works, it's genuinely impressive. When it doesn't, the error messages are frustratingly vague. Here's how to set it up right and troubleshoot the most common failure points.
The basic flow: the device ships with a supported version of Windows, boots to OOBE, connects to the internet, and Autopilot kicks in automatically, joining Microsoft Entra ID, enrolling in MDM (typically Intune), and applying your organization's apps and policies. End users can complete this themselves. IT doesn't need to touch the hardware.
Before a device can be Autopilot-enrolled, its hardware hash must be registered. In Intune, go to Devices > Enroll devices > Windows enrollment > Windows Autopilot Deployment Program > Devices and import the CSV containing the hardware hashes. OEMs can pre-register devices for you, worth setting up if you're onboarding at scale.
The most common Autopilot failure I see is the device stalling at the Enrollment Status Page (ESP) with a timeout error. Check these things in order:
- Confirm the device has internet access before OOBE starts, Autopilot is entirely cloud-dependent during provisioning
- Open Event Viewer > Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider for ESP-specific errors
- In Intune, check the device's enrollment status under Devices > All devices, look for policy assignment failures
If a device is stuck past the 40-minute ESP timeout, you can exit the ESP by pressing Ctrl+Shift+F10 to open a command prompt and running taskmgr. This is a bypass, not a fix, investigate the root policy failure afterward.
Windows Update client policies control how and when managed devices receive updates, and misconfigured policies are a silent deployment killer. The device looks fine. It's enrolled. But it's been on the same feature update version for 18 months because a Group Policy object or an Intune policy is telling it to defer updates indefinitely.
Windows Update client policies can be configured through Group Policy, Intune MDM, or the legacy Windows Update for Business registry keys. When multiple sources are in play simultaneously, conflicts happen. MDM-enrolled devices that also have GPOs applying update settings are especially prone to this.
To diagnose the current effective policy state on a machine, open PowerShell as administrator:
# Check current Windows Update policy source
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer
# Check deferral settings
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v DeferFeatureUpdatesPeriodInDays
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v DeferQualityUpdatesPeriodInDaysIf WUServer points to an internal WSUS server but the device is supposed to update through Windows Update for Business directly, that's your conflict. The WSUS redirect takes precedence and blocks WUfB policies.
In Group Policy, the relevant settings live under Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service and Manage end user experience. Make sure conflicting GPOs aren't being applied by running gpresult /h gpresult.html and opening the resulting HTML report to see exactly which policies are winning.
For Intune-managed devices, the Windows Update for Business reports in the Microsoft Intune admin center show you the update compliance status across your entire fleet. Go to Reports > Windows Updates to see which devices are deferred, which are failing, and why. This is the fastest way to spot policy conflicts at scale without touching individual machines.
After resolving the policy conflict, force a policy refresh on the affected device:
gpupdate /force
# Then trigger Windows Update detection
wuauclt /detectnowAdvanced Troubleshooting for Windows Deployment
When the standard fixes don't resolve the issue, you're usually dealing with one of three things: a domain/enterprise environment with conflicting management policies, a hardware edge case, or a deeply buried driver or filesystem issue that Setup can't automatically resolve.
Group Policy and Intune Policy Conflicts on Domain-Joined Devices
Domain-joined devices enrolled in Intune (co-management in Configuration Manager terminology) are the most complex troubleshooting scenario. You have three potential sources of policy: on-premises Active Directory GPOs, Configuration Manager, and Intune. All three can apply conflicting Windows Update and deployment settings simultaneously.
Start by checking the co-management workload authority. In the Configuration Manager console, go to Administration > Cloud Services > Co-management and verify which workloads are assigned to Intune vs. Configuration Manager. If Windows Update policies are split between both, that's likely your conflict source.
Use Event Viewer heavily during deployment troubleshooting. The key logs to check:
- Windows Logs > Application, MBR2GPT errors, setup errors, general application failures
- Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin, MDM enrollment and policy application errors
- Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational, all Windows Update activity, including policy-blocked updates (Event ID 25 = update blocked by policy)
- Applications and Services Logs > Microsoft > Windows > Autopilot, Autopilot-specific provisioning events
Bare Metal PXE Deployment Failures
If your PXE-booted bare metal deployment fails to find the WDS server, check DHCP options 66 (Boot Server Host Name) and 67 (Bootfile Name) on your DHCP scope. For UEFI clients the bootfile should be \boot\x64\wdsnbp.com, not the legacy BIOS path. Mixing these up is the most common bare metal deployment failure in environments that have recently upgraded WDS infrastructure.
Also verify that the Windows PE boot image you're using matches the architecture of the target hardware. A 32-bit WinPE image won't boot on a 64-bit UEFI machine. In the Configuration Manager console, check the boot image properties under Software Library > Operating Systems > Boot Images.
Provisioning Package Conflicts
If you're using the Windows Imaging and Configuration Designer (Windows ICD) to create provisioning packages for the MDM-free deployment scenario, conflicts between provisioning packages applied in sequence can cause silent configuration failures. Apply one package at a time during testing and use the ProvPackageAction.log in C:\Windows\Logs\Provisioning to trace which settings applied successfully.
If you've worked through all steps above and deployment is still failing with a consistent error code that doesn't appear in the Setup logs or Event Viewer in a meaningful way, especially error codes in the 0x8007XXXX range related to file system access, that's a signal to escalate. Similarly, if Windows Autopilot device registration is failing at the tenant level (not the device level), that's an account/licensing issue that requires Microsoft support to resolve. Go to Microsoft Support and use the "Get Help" path for Windows deployment, they have dedicated escalation engineers for Autopilot and Configuration Manager issues specifically.
Prevention & Best Practices for Windows Deployment
Most Windows deployment failures are preventable. Not all of them, hardware surprises happen, but the vast majority of the failures I've seen in the field trace back to skipped preparation steps, the wrong deployment method chosen for the scenario, or update policies that were set and forgotten years ago.
The single most impactful thing you can do before any deployment is build a proper deployment plan. Microsoft's official documentation covers this explicitly: start with your current OS inventory, identify which machines are eligible for in-place upgrade versus which need the Refresh or Replace approach, validate hardware compatibility, and then choose your deployment method from there. Doing this in the right order saves hours of rollback debugging later.
For enterprise environments managing Windows feature updates, Windows Update for Business reports is an underused tool. It gives you visibility into the update compliance state of every managed device before you even begin deployment, which machines are deferred, which are blocked, which haven't checked in recently. Running this report before a deployment wave means you're not discovering failures reactively.
On the infrastructure side, keep your WinPE boot images updated whenever you update the Windows ADK. Stale boot images are a persistent source of bare metal deployment failures that are completely avoidable. The rule of thumb: whenever you update to a new version of the ADK, rebuild your boot images.
For organizations using Windows Autopilot at scale, pre-register device hardware hashes with your OEM vendor instead of manually importing CSVs. Most major OEMs support Autopilot pre-registration, it eliminates the manual step entirely and means devices are ready to enroll the moment they're unboxed.
- Run
mbr2gpt /validatebefore attempting any BIOS-to-UEFI conversion, never convert without validating first, the tool will tell you exactly why it will or won't work - Keep a dedicated Windows deployment plan that maps each device type to its correct deployment scenario (in-place, Autopilot, bare metal, Replace), review it before every major deployment wave
- Set up Windows Update for Business reports in Intune before you need them, the data only starts accumulating once the workspace is configured, so set it up now
- After every failed in-place upgrade, always check
C:\$WINDOWS.~BT\Sources\Panther\setuperr.logbefore trying anything else, it will tell you the exact failure reason and save you from guessing
Frequently Asked Questions
Why does my Windows 11 upgrade keep rolling back automatically at 32% or 64%?
This is almost always a driver compatibility failure, and it's actually Windows Setup doing exactly what it's supposed to do, it detected a problem and rolled back to protect your machine. The good news is your data is completely safe and nothing is broken. Open C:\$WINDOWS.~BT\Sources\Panther\setuperr.log in Notepad and look for lines with error code 0xC1900101, that's the driver failure indicator. The log will usually name the specific driver causing the conflict. Update or uninstall that driver, then re-run the upgrade.
Can I use Windows Autopilot on a machine that's already set up and in use?
Yes, but with an important caveat, the existing machine needs to be running a currently supported version of Windows, and you'll need to reset the device to out-of-box state to go through the Autopilot OOBE flow. You can trigger this by going to Settings > System > Recovery > Reset this PC > Remove everything, but make sure the hardware hash is registered in your Autopilot profile first, otherwise you'll just get a standard OOBE without the corporate configuration. Also, the machine needs consistent internet access throughout the provisioning process, drop-outs during enrollment are a common failure point.
What's the difference between Windows Refresh and Replace deployment scenarios?
Both scenarios involve saving and restoring user state, but the key difference is whether the same physical hardware is being reused. Refresh (also called wipe and load) wipes the disk on the existing device, deploys a fresh Windows image, and then restores the user's files and settings back to that same machine. Replace is used when you're retiring old hardware and giving the user a new device, you capture the user state from the old machine using USMT, deploy Windows on the new hardware, and restore the captured state there. Both scenarios are handled through Configuration Manager task sequences in enterprise environments.
My Windows Update client policies aren't applying on my Intune-managed device, what do I check first?
Start by checking whether the device also has on-premises Group Policy applying update settings. When GPOs and Intune MDM policies conflict, GPO settings often win depending on which key they write to, this creates exactly the "policy looks right in Intune but isn't working" symptom. Run reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s in an elevated command prompt to see every update policy currently set on the machine and trace which source applied it. Also check Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin for MDM policy application failures.
Can I use a custom Windows image for an in-place upgrade?
No, and this is a point Microsoft's official documentation is explicit about. The in-place upgrade process uses the standard Windows installation media image (Install.wim) and cannot use custom images. The reason is that the upgrade process would have no way to resolve conflicts between applications in your old OS and applications that are baked into a custom image. For example, if you have App X version 1.0 installed on the current machine and your custom image includes App X version 3.0, Setup can't determine which wins. If you need to deploy a customized Windows image, use the Bare Metal or Refresh scenarios instead, those are specifically designed for image-based deployments.
What Windows Update client policies do and how do I configure them correctly in Intune?
Windows Update client policies are settings that control how devices receive, defer, and install Windows updates in a managed environment. They replaced the older Windows Update for Business settings and give IT admins control over update rings, deferral periods, active hours, and restart behavior, all without needing WSUS. In Intune, go to Devices > Windows > Update rings for Windows 10 and later to create and assign update ring policies. Set a quality update deferral (security patches, typically 0–7 days for most orgs) and a feature update deferral (major Windows versions, typically 30–90 days to allow testing). Assign the ring to a device group, and the policy will apply at next MDM check-in. Use Windows Update for Business reports to verify compliance after assignment.