For some time, I've followed a documented practice when managing my operating system images. That practice is to perform a cleanup before capturing the final WIM file. There are a few things you can do for the disk cleanup, but most commonly use of DISM /resetbase and /startcomponentcleanup yield considerable savings in the size of the final WIM. Let's take a quick look at these.
startcomponentcleanup
This command can be invoked with DISM like this:
DISM.exe /online /Cleanup-Image /StartComponentCleanup
This actually performs similar function to a built-in Scheduled Task of the same name (Windows 8+). The purpose is to clean up components automatically when the system is not in use, waiting at least 30 days after an updated component has be installed, in the case of the scheduled task. When you run the DISM command, the cleanup occurs immediately.
resetbase
This is the more invasive approach, when you understand what it does. You can run this with the previous command like so:
DISM.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
What's happening here? Well, ALL patches that are currently installed in the OS will be sealed. You are literally creating a new "base" for the install of the OS, and you can no longer uninstall patches. It does not, however, block you from removing future patches. But everything on the system to that point will become permanent.
Beware! Unintended consequences installing .NET 3.5
So why is this a problem? Most of the time, it's not, but it can bite you in two circumstances:
- You didn't install .NET 3.5 (NetFX3 features) before you reset the base, and now you need to.
- You want to change Core to GUI mode in Server 2012 R2.
Case #1 is where I ran into this problem. I had created images which accidentally omitted NetFX3 feature, using MDT Add Roles and Features, the .NET framework 3.5 had never actually installed. .NET 3.5 installs a bit differently than other components. This is because .NET files are one of the few components not staged to the component store. You must supply the SXS source directory. For a while, using the DISM command below and the SXS path worked well. That is, until recently when I refreshed my image and included more than 300 OS and Office updates by injecting the packages offline.
The symptoms of this issue will manifest when you try to add the NetFX3 feature. For example, even when you point the DISM command to a proper source, you'll get a source files error. In this example, I've already copied the sources\sxs directory from Windows 8.1 media to a local path. In some cases, you might even get lucky and find that the solution in this TechNet post solves your issue:
https://blogs.technet.microsoft.com/askpfeplat/2014/09/29/attempting-to-install-net-framework-3-5-on-windows-server-2012-r2-fails-with-error-code-0x800f0906-or-the-source-files-could-not-be-downloaded-even-when-supplying-source/
But this did not work for me.
After I got this error, I opened up the c:\windows\logs\cbs\cbs.log to find errors about missing packages and CBS_E_MISSING_PACKAGE_MAPPING_INDEX errors. Once you have that index error, it's a bad sign without an easy way out. Because the packages have been sealed into the image you can't mess with them anymore.
The only good way out of this, that is least invasive, is to perform an in-place upgrade of the same version of the OS. Afterward, you should be able to use the DISM command to add NetFX3 feature successfully.
The Solution
Bottom line: To avoid all this fuss, make sure you add NetFX3 feature into your image before you add any patches, and before you reset the base. I'm still in favor of resetting the base because it removes a solid 2 GB from my captured WIM image, which speeds up the deployment.