Technology Toolbox

Your technology Sherpa for the Microsoft platform

Jeremy Jameson - Founder and Principal



Save Significant Disk Space by Setting MaxPatchCacheSize to 0

This post originally appeared on my MSDN blog:

Since I no longer work for Microsoft, I have copied it here in case that blog ever goes away.

A little over two years ago, I wrote a post about installing Visual Studio 2005 Service Pack 1, in which I mentioned setting the MaxPatchCacheSize registry setting to 0 (in order to save some significant disk space while installing the service pack). [Note that the credit for this trick really goes to Heath Stewart -- as I mentioned in my original post.]

I've also mentioned in various posts that I make heavy use of virtualization in the "Jameson Datacenter" (a.k.a. my home lab) and that I prefer to keep my VHDs reasonably small. This is especially valuable when, for example, I need to copy a VM from one of my home servers and take it "on the road" with me to a customer site.

As such, one of the first things that I typically do when building out a new VM is to run the following from a command prompt:

reg add HKLM\Software\Policies\Microsoft\Windows\Installer /v MaxPatchCacheSize /t REG_DWORD /d 0 /f

Then I move on to installing products based on the intended purpose of the VM.

Here's an excerpt from the MSDN page for MaxPatchCacheSize:

If this per-machine system policy is set to a value greater than 0, Windows Installer saves older versions of files in a cache when a patch is applied to an application. Caching can increase the performance of future installations that otherwise need to obtain the old files from a original application source.


If the value of the MaxPatchCacheSize policy is set to 0, no additional files are saved.

To understand the value of setting MaxPatchCacheSize to 0 on a VM, take a look at the following figure, which shows the disk space usage on a freshly built Windows Server 2008 R2 VM, after installing SQL Server 2008 and subsequently running Windows Update to install all of the latest patches (including SQL Server 2008 Service Pack 1).

Disk usage on a Windows Server 2008 R2 VM with SQL Server 2008 SP1 (MaxPatchCacheSize not set)
Figure 1: Disk usage on a Windows Server 2008 R2 VM with SQL Server 2008 SP1 (MaxPatchCacheSize not set)

Note that the \Windows\Installer\$PatchCache$ folder is consuming almost 1 GB of space on the VHD.

I've mentioned before that a gigabyte or two isn't all that much when your physical hard drive is several hundred gigabytes in size. However, the same number on a 20 GB VHD is a different matter altogether.

The following figure shows the disk space usage for a similar configuration (i.e. a freshly built Windows Server 2008 R2 VM with SQL Server 2008 SP1), but this time with MaxPatchCacheSize set to 0 prior to starting the installation of SQL Server.

Disk usage on a Windows Server 2008 R2 VM with SQL Server 2008 SP1 (MaxPatchCacheSize set to 0)
Figure 2: Disk usage on a Windows Server 2008 R2 VM with SQL Server 2008 SP1 (MaxPatchCacheSize set to 0)

Observe that the $PatchCache$ folder isn't even visible in the disk usage view, and the free space on the VHD is substantially larger. You can imagine how the delta between the two configurations would increase substantially as more products -- and thus more patches -- are installed.

As noted on MSDN, the registry setting "does not affect files that have already been saved." In other words, if you set MaxPatchCacheSize to 0 after installing a bunch of products and patches, then you're pretty much stuck with the "wasted" disk space -- unless you use something like MSIZAP to clean up the Installer files.

Setting MaxPatchCacheSize to 0 doesn't come without penalty. There are rare occasions where you have to do a little more work when installing new products or features.

For example, while testing my upgrade from TFS 2008 to TFS 2010 on a new set of VMs, I first installed SharePoint Server 2010 on one of the VMs. Then I subsequently needed to install Reporting Services on the same VM (for the TFS reports). Since I had already installed the SQL Server 2008 client piece (and patched it to SP1), when I went to add Reporting Services, SQL Server Setup complained about not being able to find the version of sqlncli.msi it needed (because it was installed from a temporary folder via Windows Update but since my MaxPatchCacheSize was set to 0, it wasn't copied to the \Windows\Installer\$PatchCache$ folder).

Consequently, I simply had to extract the service pack (using the /EXTRACT command-line parameter) and search around a little for the expected file. Once I located the version it needed, SQL Server Setup continued on its way and completed successfully.

Note that I don't set MaxPatchCacheSize to 0 on physical machines (although I thought about it recently when setting up my laptop with a new 80GB SSD drive). Ultimately, it's a judgment call that you need to make based on how much disk space you are willing to trade for the convenience of simpler software and patch installations.


  1. # re: Save Significant Disk Space by Setting MaxPatchCacheSize to 0

    October 12, 2010 1:43 PM

    The first image doesn't get displayed.

    Could you please fix it?


  2. # re: Save Significant Disk Space by Setting MaxPatchCacheSize to 0

    December 9, 2010 6:57 PM
    mike good

    Good writeup.  I think everyone should be doing this.

    I have been doing same for maybe 4-5 years.  I started on physical machines, but very quickly added this to my list of mandatory steps when installing Windows on a new VM.  The costs/benefits are multiplied with VMs, so it's even more important there.

    In all these years, I have never run across a downside to this.  I expected that I'd get prompted for source media at some point, and was happy to make that tradeoff.  But this has never happened yet.  And I've kept many such physical & virtual machines up-to-date with Micrsoft Update patches, OS/Application/SQLServer service packs, etc.  

    PS - I also cannot see your first image.

Add Comment

Optional, but recommended (especially if you have a Gravatar). Note that your email address will not appear with your comment.
If URL is specified, it will be included as a link with your name.

To prevent spam from being submitted, please select the following fruit: Grapes

Please add 6 and 6 and type the answer here: