Reserved storage is the most misunderstood disk-space feature Windows has shipped in a decade. Half the fleet documentation I read treats it as a fixed-size block you can delete for a quick win, and cites a gigabyte figure Microsoft does not actually publish. The other half assumes it is simply on everywhere, because it was announced years ago and nobody has thought about it since. Both halves are wrong in ways that cost you a patch cycle.
It is not a folder. It is not a fixed size. It is not on by default on a device your management tooling built. And the command that reports its state will lie to you if you run it wrong — not by giving a wrong answer, but by giving an error that looks like an answer.
Reserved storage is a reservation, not a folder — space Windows refuses to hand to your data so servicing always has room to work. Microsoft documents that it is enabled automatically on devices with 1903-or-later preinstalled and on clean installs, and that it is not enabled by an in-place upgrade — which is why devices your imaging pipeline built often do not have it. The documented way to read the state is DISM.exe /Online /Get-ReservedStorageState, and the documented way to change it is /Set-ReservedStorageState /State:Enabled. On the device I used for this article that query returned Error: 5, Access is denied — a token problem, not a reserved-storage verdict, and the single most common way this check gets misread. Meanwhile the real space on that box was not in the reserve at all: 14.79 GB sat in component-store backups with 21 reclaimable packages and Microsoft's own tool saying cleanup was recommended.
The problem: an update fails for space on a disk with 417 GB free
Two different tickets arrive wearing the same costume.
The first is the honest one. A device genuinely runs out of room mid-download and Windows Update says so. Microsoft's troubleshooting article for 0x80070070 gives the exact user-facing string: "Updates are available, but we currently require additional space for downloading." The same article states the cause plainly — not enough disk space exists to store the updates for installation — and gives a working threshold: for best results the operating system disk should have at least 20 GB of available space.
The second ticket is the one that wastes your afternoon. The update fails, somebody checks the disk, and the disk is enormous. Nothing about the free-space number explains the failure. So the ticket gets escalated with a screenshot of a healthy drive attached, and somebody in the chain says the words "reserved storage" without being able to say what it is.
Here is the box I used to write this article. It is a real corporate Windows 11 device, build 26200.9168, display version 25H2, servicing stack 10.0.26100.9156.
417 GB free. If this machine failed an update, "add disk space" would be the wrong answer and "reserved storage is broken" would be an unproven guess. What you actually need is a way to separate three distinct conditions that all present as "update failed, space suspected":
- The disk is genuinely full, and reserved storage is irrelevant because the reserve has already been consumed.
- The disk has room, but reserved storage was never enabled on this device, so servicing has no protected working set and competes with user data.
- The disk has room, reserved storage is fine, and the real consumer is the component store — which is where the space on most long-lived devices has actually gone.
Why it happens: the reserve is set at deployment time, not toggled at will
What Microsoft actually says it is for
The support article is short and worth reading literally. Windows "reserves a portion of storage space on your device for use by temporary files, caches, and other files", and the point of it is to "make sure your device can successfully update and that it runs its best".
Then it adds the sentence that most people miss: "When your device is low on space, Windows will clear reserved storage so it can be used for other processes, like a Windows update." The reserve is not a museum exhibit. It is designed to be emptied and reused. A reserve that shrinks under pressure is a reserve that is working correctly, not one that is leaking.
The DISM documentation frames the purpose in one line: reserved storage "increases the likelihood that Windows updates can be downloaded and installed without users having to free disk space." Likelihood. Not guarantee. It buys headroom; it does not abolish the disk-full failure mode.
The enablement rule that catches everyone
This is the part that turns an assumption into an incident. Microsoft's release documentation states the condition in one sentence: reserved storage "will be enabled automatically on new PCs with Windows 10, version 1903 or later pre-installed, and for clean installs. It will not be enabled when updating from a previous version of Windows 10."
Read the last clause again. An in-place upgrade does not turn it on. So the state of reserved storage on any given device is a fact about how that device came into existence, not a fact about which Windows version it is running today. A 25H2 device that started life as a 1809 build and has been upgraded forward five times can be sitting there with no reserve at all, indistinguishable from its neighbour by version number alone.
The managed-fleet wrinkle is documented just as plainly, on the DISM page itself. For devices that connect directly to Windows Update, reserved storage works out of the box. But on IT-managed devices using tools such as Windows Server Update Services or Configuration Manager, the documentation says reserved storage "doesn't work automatically." The recommended pattern for those environments is the opposite of intuition: disable the reserve before downloading and installing an update, then enable it again once the installation has completed.
| How the device was built | Reserved storage state | What that means for you |
|---|---|---|
| OEM device shipped with 1903 or later preinstalled | Enabled automatically | Nothing to do; verify anyway before you rely on it |
| Clean install from media | Enabled automatically | The state travels with the install, not the release |
| In-place upgrade from an earlier build | Not enabled | The most common silent gap in a long-lived fleet |
| Imaged or upgraded through WSUS or Configuration Manager | Documented as not working automatically | Manage it explicitly around the update window |
| Sysprep generalized image | Whatever you set before generalizing | Changes are reflected in the generalized image — set it once, inherit it everywhere |
That last row is the leverage point. Because a change to the reserved-storage state survives Sysprep generalize, the right place to decide this is your image, not a remediation script chasing thousands of devices after the fact.
How the reserve interacts with temporary files during servicing
The reserve exists so that servicing scratch space is always available, and DISM's own parameter documentation tells you where that scratch space lands. The ScratchDirectory parameter specifies "a temporary directory that will be used when extracting files for use during servicing", and if you do not specify one, the documentation states the \Windows\%Temp% directory is used, with a randomly generated hexadecimal subdirectory name for each run. Crucially: "Items in the scratch directory are deleted after each operation."
That is the mechanism in one sentence. Servicing expands package payloads into a scratch directory under the Windows temp path, works, then cleans up. Reserved storage is the guarantee that the expansion has somewhere to go. When it does not, you get a space failure at expansion time even though the download succeeded.
Which makes the 10.34 GB I measured in C:\Windows\Temp interesting rather than alarming. Scratch directories that were supposed to be deleted after each operation accumulate when operations do not finish cleanly. That is a symptom worth reading, not a folder to reflexively empty.
SoftwareDistribution, empty Windows\Temp, run sfc /scannow, reboot — destroys exactly the evidence that would have told you which of the three conditions you were in. Once the scratch directories and the download cache are gone you can no longer tell whether the failure was expansion, download, or reservation. Measure first. The measurements below are all read-only and take under a minute.How to verify: read the state, then read the size, then read the store
Five steps, in this order. Each one is read-only. Each one rules something out.
Step 1 — ask DISM for the state, and be suspicious of the answer
The documented query is a single command, supported only against an online image:
An operator who sees that and writes "reserved storage check failed, appears disabled" in the ticket has just injected a false fact into the investigation. Error 5 says the process could not perform the operation. It says nothing whatsoever about whether a reserve exists.
The differential test takes ten seconds: run a second, unrelated, read-only DISM query in the same shell. If that also returns Error 5, your token is the problem, not the feature.
The DISM log confirms the diagnosis without ambiguity. Two lines from C:\Windows\Logs\DISM\dism.log, captured at the moment of that run:
There is a second way to get a meaningless answer, and it bites anyone who works in a POSIX shell on Windows. Git Bash, MSYS2 and similar environments rewrite arguments that look like absolute paths. /Online looks exactly like an absolute path.
One command, three completely different failure modes, none of which is a reserved-storage state. This is why step 1 is "be suspicious of the answer" rather than "read the answer".
Microsoft.Dism.Commands.ReservedStorageStateObject — not a documented string. Pipe it through Format-List * on one device, look at the properties, then build your detection. Do not guess a string you have never seen on your own fleet.Step 2 — corroborate with the reserve manager values
Windows keeps the reserve's own bookkeeping in the registry, and it is readable without elevation. This is genuinely useful as a second opinion when the DISM query is blocked. It comes with a hard caveat that I want to state before the data rather than after it: Microsoft does not document these value names. I read them from a live device; I did not find them described anywhere on Microsoft's documentation sites. Treat them as a corroborating read-only signal, never as a supported interface, and never write to them.
| Value | Meaning (inferred from the name — undocumented) | What to look for |
|---|---|---|
ShippedWithReserves (DWORD) | Whether this installation came into being with reserves in place | 1 on a device that was shipped or clean-installed with the reserve; 0 is your strongest hint of an upgraded-in device with no reserve |
BaseHardReserveSize (QWORD) | Bytes in the primary reservation | A non-zero value is the clearest evidence a reserve exists at all. Divide by 1073741824 for GB |
BaseSoftReserveSize (QWORD) | Bytes in a second, softer tier of reservation | Present alongside the hard reserve; the split is an observation, not a published specification |
HardReserveAdjustment (QWORD) | A running correction applied to the hard reserve | Small and non-zero on a healthy device — evidence the reserve is being actively maintained rather than sitting inert |
MinDiskSize (QWORD) | A volume-size floor associated with the feature | Compare it against the 20 GB free-space figure in Microsoft's 0x80070070 article — they line up suspiciously well |
PassedPolicy (DWORD) | Whether policy evaluation permitted the reserve | 0 here alongside a zero reserve size points at configuration, not corruption |
DisableDeletes (DWORD) | Whether the reserve is currently blocked from clearing itself | Non-zero is worth noting, given the documented behaviour is that Windows clears the reserve when space is low |
ActiveScenario (DWORD) | Whether a servicing scenario currently holds the reserve | Non-zero is the likely reason a /Set-ReservedStorageState /State:Disabled attempt is refused |
TiAttemptedInitialization (DWORD) | Whether the Trusted Installer has tried to initialise the reserve | 1 with a zero reserve size is the interesting combination: it tried and did not get one |
Here is what those values actually held on the lab device.
Notice what I am not doing with that. Microsoft does not publish a fixed size for reserved storage, and I am not going to invent one from a single sample. Five gigabytes plus 1.5 gigabytes is what this box holds today; the documented behaviour is that the reserve varies and gets cleared under pressure. Anyone quoting you a universal GB figure for reserved storage is quoting folklore.
ShippedWithReserves to 0 to reclaim the space. That is an undocumented registry write to a servicing component, and Microsoft ships two supported interfaces — the DISM switch and the PowerShell cmdlet — specifically so you do not have to do it. Use them. A registry hack that appears to work is still a registry hack that your next servicing-stack update is under no obligation to respect.Step 3 — check the event log for what servicing actually reported
The 0x80070070 article tells you to review a specific channel, and it is the same channel that carries the ordinary download-and-install narrative, so you can see the good runs and the bad run side by side.
| Event ID | Message | What it tells you |
|---|---|---|
| 26 | Windows Update successfully found N updates | Detection worked. The client reached a service and got a list. Rules out scan-side failure entirely |
| 41 | An update was downloaded | The payload arrived on disk. A space failure after this point is an expansion or installation failure, not a download failure — which is exactly the failure reserved storage is meant to prevent |
Both of those I observed directly on the lab device. The distinction between them is the whole diagnostic: if you have a 41 and then a failure, the bytes were fetched and the problem is what happened next. If you never get a 41, you are looking at the download-side space failure that Microsoft's article describes, where the log records a failed transfer into C:\Windows\SoftwareDistribution\Download\... with error 0x80070070.
The servicing side of the story lives in a different channel, and it is the one that distinguishes "staged" from "installed".
| Event ID | Message | What it tells you |
|---|---|---|
| 2 | Package <KB> was successfully changed to the Staged state | The payload is expanded and parked. Staging is the step that needs scratch space, so a successful stage means expansion had room |
| 4 | A reboot is necessary before package <KB> can be changed to the Installed state | Servicing is waiting on you, not on disk. Do not go hunting for space — go and reboot |
Both observed on the lab device, Event 4 against KB5120708. A device sitting on a pile of Event 2s with no matching Event 4 or installed state is a device where staging succeeded and something else stalled — and staging succeeding is affirmative evidence that scratch space was available.
Step 4 — identify the binaries, so you know what you are actually talking to
Reserved storage has no service of its own and no dedicated executable. It is a property of the servicing stack, exposed through the DISM API. Knowing which file implements which layer stops you chasing the wrong component.
| Binary | Where it actually lives | Role |
|---|---|---|
DismAPI.dll | C:\Windows\System32\dismapi.dll | "DISM API Framework". Microsoft documents this as the DLL exporting DismSetReservedStorageState, with header DismAPI.h and library DismAPI.lib. This is the actual programmatic interface to the feature |
DismCore.dll | C:\Windows\System32\Dism\DismCore.dll — note the Dism subdirectory, not System32 itself | "DISM Core Framework". The provider host DISM loads per session |
Dism.exe | C:\Windows\System32\Dism.exe | "Dism Image Servicing Utility". The command-line front end that parses /Get-ReservedStorageState |
Microsoft.Dism.PowerShell.dll | C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Dism\ | Implements Get-WindowsReservedStorageState and Set-WindowsReservedStorageState. Verified on-device as the declaring assembly for both cmdlets |
TrustedInstaller.exe | C:\Windows\servicing\ — not System32 | "Windows Modules Installer". The service that performs the servicing transaction the reserve exists to protect |
On the lab device the three DISM binaries were all version 10.0.26100.8457 and TrustedInstaller.exe was 10.0.26100.7019 — on an OS build of 10.0.26200.9168. That version skew is normal and worth internalising: the servicing components are versioned independently of the OS build, so "my DISM is older than my Windows" is not a fault.
Step 5 — go and look at the component store, which is where the space actually went
This is the step that resolves most of these tickets, and it has nothing to do with reserved storage. Reserved storage is a few gigabytes of deliberate reservation. The component store is tens of gigabytes of accumulated servicing history, and it is the answer far more often.
Fourteen point seven nine gigabytes against a six and a half gigabyte reserve. If you spend your afternoon disabling reserved storage to reclaim space, you will have traded away your servicing headroom to recover less than half of what a documented cleanup would have given you for free. That is the trade this article exists to stop you making.
The fix: set the state deliberately, clean the thing that is actually full
Setting the state
Two supported interfaces, both online-only. The DISM form:
DISM.exe /Online /Set-ReservedStorageState /State:Disabled
And the PowerShell form, Set-WindowsReservedStorageState -State Enabled, where -State is mandatory and accepts exactly Enabled or Disabled.
Set-WindowsReservedStorageState -State Enabled -Online. There is no -Online parameter. I checked the cmdlet metadata on the device rather than trusting the page: the declared parameters are State, LogPath, ScratchDirectory and LogLevel, and Online is absent from both the get and the set cmdlet. Copy the documented example verbatim into a deployment script and it fails on parameter binding. The syntax block on the same page is correct; the example is not.The documented refusal condition matters more than the syntax. If reserved storage is in use it may not be disabled, and the returned error is: "This operation is not supported when reserved storage is in use. Please wait for any servicing operations to complete and then try again later."
That is not a bug to work around. It is the reserve doing its job while a servicing operation holds it. Which is precisely why the WSUS and Configuration Manager pattern in the documentation is disable-before, enable-after, rather than disable-during: you get a window when nothing is holding the reserve, and you use it.
Cleaning the thing that is actually full
If step 5 gave you a cleanup recommendation and a pile of reclaimable packages — 21, on the lab device — that is your space. The documented cleanup is DISM /Online /Cleanup-Image /StartComponentCleanup, and it removes superseded component versions.
There is a variant, /ResetBase, and you need to understand the cost before you type it. It reclaims more, and it does so by making the superseded versions unrecoverable. After a reset base you cannot uninstall the updates whose backups you just deleted. On a device that is failing updates — that is, a device where you may well need to roll something back — deliberately destroying your rollback path is the wrong instinct. Clean first, keep the ability to reverse, and reserve /ResetBase for images you are finalising rather than devices you are troubleshooting.
And on the 10.34 GB in C:\Windows\Temp: the documented behaviour is that servicing scratch subdirectories are deleted after each operation, so a large accumulation is a record of operations that did not finish cleanly. Read it as a symptom first. Emptying it before you have looked at what is in there converts a diagnosable pattern into an unexplained absence.
Proof it worked: the four numbers that should move
A word on honesty first. On the lab device I ran read-only commands only. I did not change the reserved-storage state on a live corporate endpoint to generate a screenshot, and neither should you. Every figure quoted above is a real measurement; the state-change outputs below are the documented strings from Microsoft's own pages, clearly labelled as such rather than passed off as captured.
Re-measure these four things, in this order, and check each against what it should have done.
| What to re-read | Command | What proves success |
|---|---|---|
| Reserved storage state | DISM.exe /Online /Get-ReservedStorageState | It returns a state at all, from a genuinely elevated shell. Compare against the string you captured on a known-good device — not against a string you assumed |
| Reserve bookkeeping | Read ReserveManager read-only | BaseHardReserveSize moves from zero to non-zero after enabling. This is the corroboration that the switch did something, not just that it exited zero |
| Component store | DISM /Online /Cleanup-Image /AnalyzeComponentStore | "Backups and Disabled Features" falls, "Number of Reclaimable Packages" drops toward zero, and "Component Store Cleanup Recommended" flips to No |
| The update itself | Event 41 then a Setup Event 2, then Event 4 or an installed state | The narrative completes. Downloaded, staged, installed — with no space error in between |
That third row is the one to write in the ticket. "Component Store Cleanup Recommended: No" is a machine-generated statement from Microsoft's own tool that the space problem you were chasing is resolved. It is far better evidence than a free-space number, because free space fluctuates and that flag does not.
The last row is the real acceptance test. Reserved storage is not an end in itself; it is a means of making the download-stage-install sequence survive a tight disk. If you can watch that sequence complete in the event log, the reserve did its job — whether or not you ever saw a number that told you how big it was.
And if you take one thing from this: on a device with 417 GB free, the answer was never going to be reserved storage. It was 14.79 GB of servicing history that Microsoft's own tool had already flagged, sitting behind a question nobody had asked. The reserve is worth understanding precisely so you stop blaming it.
References
- DISM Storage reserve command-line options - the primary source:
/Get-ReservedStorageState,/Set-ReservedStorageState /State:, the in-use refusal message, the Sysprep behaviour, and the WSUS / Configuration Manager guidance. - Get-WindowsReservedStorageState - online-image only, supported from Windows 10 version 2004, and the documented output type
Microsoft.Dism.Commands.ReservedStorageStateObject. - Set-WindowsReservedStorageState - the mandatory
-Stateparameter and its two accepted values. Also the page whose example includes a-Onlineparameter the cmdlet does not have. - DismSetReservedStorageState function - the API beneath the tooling, with the requirements table naming
DismAPI.h,DismAPI.libandDismAPI.dll. - DISM API Constants -
DISM_RESERVED_STORAGE_ENABLEDandDISM_RESERVED_STORAGE_DISABLED, the two states the feature actually has. - Troubleshoot Windows Update Error Code 0x80070070 - the user-facing message, the cause, the 20 GB recommendation, and the channel to review.
- What's new in Windows 10, version 1903 - the enablement rule verbatim: automatic on preinstalled and clean installs, not enabled by an in-place upgrade.
- Determine the Actual Size of the WinSxS Folder -
/AnalyzeComponentStoreand how to read every field in the report used above. - How reserved storage works in Windows - the purpose in Microsoft's own words, the clearing-under-pressure behaviour, and the Settings path to view it.