Save Significant Disk Space by Setting MaxPatchCacheSize to 0
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).
.png)
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.
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.
Important
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.
Comments
Anonymous
October 12, 2010
The first image doesn't get displayed. Could you please fix it? Thanks.Anonymous
December 09, 2010
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.