The WinRE partition is too small: 0x80070643 and the recovery-partition resize you cannot avoid

A security update fails. The error is 0x80070643. You do what any sane administrator does: you check the Windows Update service, you clear the SoftwareDistribution folder, you run the troubleshooter, you re-run the scan. Nothing changes. The update fails again, next month it fails again, and the device sits in your compliance report as permanently behind.

The problem is not Windows Update. The problem is disk geometry. Specifically, it is a partition most administrators have never opened, never sized, and never thought about since the day the OEM shipped the machine. This post explains what that partition is, why a security update needs free space inside it, how to find out how many of your devices are affected, and what the documented repair actually does to the disk. The repair involves deleting and recreating a partition on a running machine, so the risk section is not decoration.

The problem: an update that fails with a code that tells you nothing

Every few months Microsoft ships a Windows Recovery Environment update. It is a small, separate item in Windows Update, with a title like "Windows Recovery Environment update for Windows 10, version 21H2 and 22H2". On some devices it installs in seconds. On others it fails, and keeps failing, forever.

The failure code you see is 0x80070643. That is an HRESULT built from the Win32 facility, wrapping Win32 error 0x643, which is 1603 in decimal. Microsoft's Windows Installer error reference documents 1603 as ERROR_INSTALL_FAILURE, described simply as "A fatal error occurred during installation." That is the whole message. It says an install failed. It does not say anything about partitions, disks, or recovery.

The reliable signal is in the event log, and Microsoft documents it. Its resize guidance states that when this happens you get "a system event with an ID of 4502 triggered in C:\Windows\System32\winevt\logs\system.evtx", with details showing "Windows Recovery Environment servicing failed" and an ErrorPhase of 2. Here is what to look for.

The mirror image of that event is ID 4501. Microsoft's article on verifying the installed WinRE version tells you to search the System log for WinREAgent entries and look for "Event ID: 4501 Servicing succeeded", which carries the text "The Windows Recovery Environment version is now:" followed by a version number. So the pair is simple: 4501 means the recovery image was replaced, 4502 means it was not.

Before anything else, ask the device what it thinks its own recovery configuration is. ReAgentc.exe is the in-box tool for that, and /info is the read-only option. Read the output top to bottom: status tells you whether WinRE is switched on at all, location tells you which partition holds it, and the version tells you how current the image is.

Why it happens: WinRE lives in its own partition, and the update replaces the whole image

To understand the free-space requirement you need three facts about how WinRE is stored and serviced. Take them in order.

Fact one: WinRE is a file, and it is deliberately not on your C drive. The recovery environment ships as a single Windows Imaging Format file, winre.wim. Microsoft's WinRE technical reference describes the flow: Windows Setup first places winre.wim in the Windows partition under \Windows\System32\Recovery, and then during the specialize configuration pass copies it into the recovery tools partition "so that the device can boot to the recovery tools even if there's a problem with the Windows partition". The same page states the recovery tools must be in a separate partition so users "can use WinRE even if the Windows partition is encrypted with Windows BitLocker Drive Encryption". A recovery tool stored on the volume it exists to recover is not a recovery tool.

Fact two: that file is big. Microsoft's UEFI/GPT partition guidance states that "the recovery image, winre.wim, is typically between 500-700MB, depending on what drivers, languages, and customizations you add", and adds that "the file system itself can take up additional space. For example, NTFS may reserve 5-15MB or more on a 750MB partition."

Fact three, and this is the one that causes the failure: WinRE is not patched in place. Microsoft's technical reference is unambiguous. "Unlike the normal OS update process, updates for Windows RE don't directly service the on-disk Windows RE image (winre.wim). Instead, a newer version of the Windows RE image replaces the existing one", with boot-critical drivers from the running OS and any customizations under \Sources\Recovery injected or migrated into the new image.

Put those together and the arithmetic is obvious. To replace a 600 MB image you need somewhere to put the new 600 MB image before you delete the old one. That somewhere is the recovery partition, and if it does not have room, the swap cannot happen. This is the whole bug.

Here is the chain, from trigger to failure, in order:

1. Windows Update (service wuauserv) offers a Windows Recovery Environment update, or a monthly cumulative update that carries WinRE servicing. Microsoft moved to servicing WinRE through the monthly cumulative update from 27 June 2023, for devices getting updates from Windows Update or Windows Server Update Services (WSUS).
2. The servicing component, which logs under the name WinREAgent, builds a new recovery image and stages it toward the recovery partition, writing progress into %WINDIR%\Logs\WinREAgent\setupact.log.
3. Deployment Image Servicing and Management (DISM) does the image work. You can see its calls interleaved in the same log.
4. If the staging succeeds, ReAgentc.exe repoints the configuration at the new image and the System log gets a WinREAgent event 4501.
5. If there is not enough free space, staging fails. Windows Update reports a generic install failure. The System log gets WinREAgent event 4502 with ErrorPhase 2.

Microsoft also documents what Windows tries to do about a partition that is too small, and this is the part that should make you cautious. The technical reference states the update process "makes every effort to reuse the existing Windows RE partition without any modification", but where the new image does not fit:

• If the recovery partition is immediately after the Windows partition, Windows shrinks the Windows partition and grows the recovery partition.
• If the recovery partition is not immediately after the Windows partition, Windows shrinks the Windows partition, creates a brand new recovery partition, and the existing recovery partition "will be orphaned".
• If the recovery partition cannot be reused and the Windows partition cannot be shrunk, the new image is installed onto the Windows partition and the existing recovery partition "will be orphaned".

That third outcome is quietly significant: it silently ends BitLocker-compatible recovery, because the recovery image is now on the encrypted volume. Partition order on disk is therefore not cosmetic. It decides which of those three paths your device takes.

The free-space number is not one number

The brief for this post asked for "the documented free-space requirement". There is no single one. Microsoft publishes several figures in different places, for different purposes, and you should know all of them before you pick a threshold for your fleet.

Source documents for each row are linked in References.

System files and binaries in the flow

These are the actual files involved. Knowing which one does what is the difference between reading a log and guessing at it.

Registry: there is almost nothing here, and that matters

If you have been searching for a registry key that reports WinRE health, stop. WinRE's configuration is not registry-backed. Its state lives in ReAgent.xml and in the Boot Configuration Data store. The values below are the ones a detection script legitimately reads, and they are about identifying the OS build so you can correlate it against the WinRE image version.

Shared parent key:

How to verify: measure the fleet before you touch a single disk

The single most important thing in this whole topic: find out how many devices are affected before you deploy anything that modifies a partition. The remediation is destructive, and if it turns out that eleven laptops need it, eleven laptops is a helpdesk ticket, not a fleet-wide script campaign.

Step one: read the geometry on one device

Two commands give you everything. Get-Partition tells you where the recovery partition sits and how big it is; Win32_Volume tells you how much of it is free. You need both, because Get-Volume will not reliably show a partition with no drive letter.

Step two: use the read-only companion script for the fleet

Typing those commands on one machine is fine. Doing it on nine hundred is not. The companion script for this post, Get-WinRePartitionReadiness.ps1, does the whole readiness read in one pass and returns an exit code you can use as an Intune detection result. It is deliberately and strictly read-only: it never calls reagentc /disable, never invokes diskpart, and contains no partition-modifying cmdlet at all.

It reports the OS build, WinRE status and image version, the recovery partition's disk and partition index, its capacity and free space, whether the partition sits immediately after the OS partition, the ReAgent.xml stage state, the count of WinREAgent 4501 and 4502 events, and which WinRE log files exist. It ends in one of three words: READY, NOT-READY, or READ-FAILED.

Step three: log files and what to grep for

When a device says NOT-READY and you want to know what the last servicing attempt actually did, these are the files. All five were confirmed present on the live device used for this post.

There is also a working directory, %SYSTEMDRIVE%\$WinREAgent, that appears during servicing and is cleaned up afterwards. If it is present on an idle device, servicing did not finish tidily. It was absent on the test device, which is the expected state.

Step four: services and scheduled tasks

Nothing here needs configuring, but knowing the expected state saves you chasing the wrong component.

Step five: fleet detection through Intune

Intune has no setting for this. Say that out loud before you go looking for one. There is no Settings Catalog entry, no Configuration Service Provider (CSP) node, and no Group Policy object that sizes or repairs a recovery partition. The Recovery CSP exists and it covers real WinRE functionality -- pre-configured Wi-Fi credentials for the recovery environment, quick machine recovery, whether WinRE may reuse Wi-Fi profiles saved in Windows -- but partition geometry is not among its nodes. Partition work happens through diskpart and reagentc, which means script deployment, full stop.

The right home for the read-only detection pass is Intune Remediations. Deploy the companion script as a detection script with no remediation script attached, and you get a fleet-wide count without a single write operation.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices > Manage devices > Scripts and remediations. Note that this node was previously called Proactive Remediations.
3. Select the Remediations tab, then choose Create script package.
4. On Basics, give it a name such as Detect - WinRE recovery partition readiness and a description. Publisher defaults to your name.
5. On Settings, select the folder icon next to Detection script file and upload Get-WinRePartitionReadiness.ps1. Leave Remediation script file empty for the detection-only phase.
6. Set Run this script using the logged-on credentials to No. The script needs administrator rights, so it must run in system context.
7. Set Enforce script signature check to No unless your script is signed and the certificate is in the device Trusted Publishers store.
8. Set Run script in 64-bit PowerShell to Yes. The Storage module cmdlets behave correctly there.
9. Select Next, apply any Scope tags, then on Assignments pick a pilot device group. Do not assign to All Devices on the first pass.
10. Set the Schedule to Daily. Complete Review + create.
11. After a day, return to the script package and select Device status, then use Export to pull the output as a CSV. Devices returning exit code 1 with the word NOT-READY are your affected population.

Two prerequisites, both documented. Devices must be Microsoft Entra joined or Microsoft Entra hybrid joined and MDM-enrolled running Windows Enterprise, Professional or Education, or co-managed. Licensing requires Windows Enterprise E3 or E5, Windows Education A3 or A5, or Windows Virtual Desktop Access per user. Also remember the detection contract: exit code 1 means the issue was found, and any other exit code -- including an empty output -- is read as "issue not found".

Group Policy: no setting for this, but one relevant trap

There is no Group Policy path that sizes a recovery partition, because there is no policy-configurable setting behind it. What Group Policy can do to WinRE is break it, and Microsoft documents exactly one such case. If the security option blocking Microsoft accounts is set to "User can't add or log with Microsoft account", a System Restore attempt inside WinRE fails with a message claiming there are no administrator accounts on the PC.

1. Open the Group Policy Management Editor on a domain controller, or gpedit.msc for local policy.
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
3. Find Accounts: Block Microsoft accounts.
4. If it is set to Users can't add or log on with Microsoft accounts, you have this trap. Microsoft's documented workarounds are to avoid that value, or to set the MDM policy Security/RecoveryEnvironmentAuthentication to 2.
5. Run gpupdate /force on a test device, then verify by booting to WinRE and attempting System Restore.

The fix: the documented resize, and why you should not type it by hand

Microsoft's guidance for manually resizing the partition is the reference for this section. Read the sequence before you read the commands, because the shape of it is what carries the risk.

1. Turn WinRE off with reagentc /disable. This moves winre.wim back to C:\Windows\System32\Recovery and removes the boot entry. For the duration of the next steps, the device has no recovery environment.
2. Shrink the OS partition by 250 MB to free up space.
3. Delete the existing recovery partition.
4. Create a new, larger partition with the correct type identifier and format it NTFS.
5. Turn WinRE back on with reagentc /enable, which stages the image into the new partition and rewrites the boot entry.

Step three is the one to sit with. You are deleting a partition on a running production machine, and between steps one and five the device cannot boot to recovery. Here is the documented command sequence, with what each line does.

Use Microsoft's script, not your own

Do not hand-roll this. Microsoft publishes sample scripts for exactly this job, and they handle the cases a hand-typed diskpart session will not.

• The partition-extension sample in "Add an update to Windows RE" on Microsoft Learn. It takes -SkipConfirmation and -BackupFolder parameters for unattended runs. Critically, it checks the layout before acting: it exits cleanly if the recovery partition already has 250 MB free, refuses to proceed if the recovery partition is not immediately after the OS partition, uses any unallocated gap between them instead of shrinking, backs up the old partition contents, and clears the stage location in ReAgent.xml before repartitioning. It also insists you reboot first, because pending partition operations must be finalised.
• The CVE remediation scripts published with Microsoft's WinRE security guidance -- PatchWinREScript_2004plus.ps1 and its general-purpose sibling for the CVE-2022-41099 work, and Patch_WinRE_Generic.ps1 for CVE-2024-20666. These patch the image rather than resize the partition, and the CVE-2024-20666 script additionally reconfigures WinRE for the BitLocker service where a Trusted Platform Module (TPM) protector is present.

Cite them, download them from Microsoft, read them, and test them. Do not paste them into a post like this one and call them your own -- and do not run any third-party rewrite of them without diffing it against the original.

What you can actually configure through Intune for WinRE

Since there is no partition setting, here is the WinRE surface Intune does give you, and it is worth having: quick machine recovery. Available on Windows 11 version 24H2 build 26100.4700 or later, it uses "a secure and connected Windows Recovery Environment (WinRE) to scan Windows Update for remediation options" so devices can recover from boot failures without a technician. It is configured through the Recovery CSP, and it is disabled by default on enterprise-managed devices.

1. In the Intune admin center, go to Devices > Manage devices > Configuration.
2. Select Create > New policy. Choose Platform Windows 10 and later and Profile type Settings catalog.
3. Name the profile, for example WinRE - quick machine recovery, then select Next.
4. On Configuration settings, select Add settings and search the picker for Recovery, which surfaces the Recovery CSP settings.
5. Enable cloud remediation, and optionally auto remediation with a scan interval. The underlying CSP node is documented under Recovery CSP as QuickMachineRecovery.
6. Assign to a pilot group and complete Review + create.
7. Verify on a device with reagentc.exe /getrecoverysettings, which prints the applied XML. There is also reagentc.exe /setrecoverysettings /path settings.xml for the command-line route and reagentc.exe /clearrecoverysettings to remove it.

Proof it worked: real output from a live device

Everything below is a genuine run on a Windows 11 Enterprise 25H2 device, build 26200.9168, with the computer name and BCD identifier replaced. Nothing here is invented.

The ReAgent.xml read is worth showing on its own, because it is the file Microsoft's own resize script edits. An empty ImageLocation with a zero GUID is the healthy idle state.

Finally, the independent confirmation. Microsoft's documented method is to take the location from reagentc /info and ask DISM for the image version, then check that the ServicePack Build is greater than or equal to the UBR of the update you applied.

Where does that leave you? The honest answer for most fleets is: check first, and you may not need to do anything. Devices imaged in the last couple of years tend to ship with 1 GB or larger recovery partitions and sail through. The affected population is usually older hardware, custom partition layouts, and images built before Microsoft moved WinRE servicing into the monthly cumulative update in June 2023. That is a set you can enumerate, ring-fence, and remediate carefully -- which is a completely different job from pushing partition surgery to everything you own.

References

• KB5028997: Instructions to manually resize your partition to install the WinRE update - Microsoft Support. The documented manual command sequence, the event 4502 signal, and the system.evtx path.
• Add an update to Windows RE - Microsoft Learn. The 250 MB recommendation, the ReAgentC /mountre and /unmountre servicing flow, and the official partition-extension sample script.
• Windows Recovery Environment (Windows RE) - Microsoft Learn. What WinRE is, the image-replacement servicing model, the three fallback outcomes when the partition is too small, and the Block Microsoft accounts known issue.
• UEFI/GPT-based hard drive partitions - Microsoft Learn. Recovery partition minimum size, free-space guidance, the DE94BBA4-06D1-4D40-A16A-BFD50179D6AC Type ID, and why the partition belongs immediately after Windows.
• Disk partition requirement for using Windows RE tools on a UEFI-based computer - Microsoft Learn. The 300 MB partition minimum, the version-specific free-space table, and the "double the specified free space" note.
• REAgentC command-line options - Microsoft Learn. Every documented ReAgentc.exe option including /info, /enable, /disable and /setreimage.
• KB5098815: Windows Recovery Environment update for Windows 10, version 21H2 and 22H2 - Microsoft Support. A current example of the requirement text: "This update requires 250 MB of free space in the recovery partition to install successfully."
• Methods to verify the WinRE version installed - Microsoft Support. The three documented verification methods, and the 4501 "Servicing succeeded" event.
• KB5025175: Updating the WinRE partition on deployed devices (CVE-2022-41099) - Microsoft Support. The PatchWinREScript_2004plus.ps1 sample script.
• KB5034957: Updating the WinRE partition on deployed devices (CVE-2024-20666) - Microsoft Support. The Patch_WinRE_Generic.ps1 sample script and its BitLocker TPM handling.
• Quick machine recovery - Microsoft Learn. The Recovery CSP configuration surface and the reagentc.exe /getrecoverysettings verification command.
• Use Remediations to detect and fix support issues - Microsoft Intune documentation. Admin center path, prerequisites, licensing, and the exit 1 detection contract.
• MsiExec.exe and InstMsi.exe error messages - Microsoft Learn. Documents 1603 as ERROR_INSTALL_FAILURE, "A fatal error occurred during installation."

No community deep-dive is cited here. Several well-known endpoint blogs were checked for on-topic coverage of the recovery-partition free-space failure and none verified as a genuine match, so the table is omitted rather than padded. An omitted citation is honest; an inherited one is not.