Shrink your Windows server and client images

When creating Windows images with lot's of updates, it's possible to shrink them before or after capturing the image. When deploying systems with less free disk space (like thin clients) this may be needed to fit. The DISM tool contains multiple servicing commands related to the component store (or the WINSXS directory). This location is used during servicing operations within Windows installations. Servicing operations include, but are not limited to, Windows Update, service pack, and hotfix installations.

The component store contains all the files that are required for a Windows installation. And, any updates to those files are also held within the component store as the updates are installed. This causes the component store to grow over time as more updates, features, or roles are added to the installation. The component store uses NTFS hard links between itself and other Windows directories to increase the robustness of the Windows platform.

The following commands can be used to shrink Windows installations and/or WIM images:

When creating a reference image use the online command:
Dism.exe /online /Cleanup-Image /StartComponentCleanup
Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
Dism.exe /online /Cleanup-Image /SPSuperseded

When the image is already created, mount it and use the offline command:
Dism /image:<path> /Cleanup-Image /StartComponentCleanup

You can also run the following command to check the status of the Component Store:
Dims.exe /Online /Cleanup-Image /AnalyzeComponentStore

This can save multiple gigabytes on the image size!

For more information:
Clean Up the WinSxS Folder
How to address disk space issues that are caused by a large Windows component store (WinSxS) directory
How to Clean up the WinSxS Directory and Free Up Disk Space on Windows Server 2008 R2 with New Update

Deployment error on Apply Driver Package (DISM) step

Recently deployment went wrong on a few system types, part of a lot different system types. At every deployment it went wrong on the Apply Driver Package step. At earlier deployments all went fine, but now it stops working. Both were heavy HP workstations with 16GB and 32GB memory onboard. A lot of errors in SMSTS.log and DISM.log were seen.

SMSTS.log
-Dism failed with return code -2147467259
-Failed to add driver to driver store. Code 0x80004005
-Failed to provision driver. Code 0x80004005
-Exiting with return code 0x80004005
-Failed to find a matching version

DISM.log
Failed to find a matching version for servicing stack: E:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.17592_none_0b0e4b4025cf4049\ [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
Failed to find servicing stack directory in online store. [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
Failed to open the registry root: n/a, key: Microsoft\Windows NT\CurrentVersion\ProfileList. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to query for path to user profiles directory. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to load the default user profile registry hive. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}E:/Windows/System32/config/SOFTWARE, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
Failed to load offline store from boot directory: '\\?\E:\' and windows directory: '\\?\E:\Windows\' [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to initialize store parameters with boot drive: E:\ and windows directory: E:\Windows [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]

After some digging I found the following solution:
Deployment failures with Precision systems
Win2008R2/Win7: STOP 0xF4 during Task Sequence / OS Deployment
Corrupt Segoe UI font and .NET framework after OSD with 2012 R2 CU1

It mentions:
The issue in this case occurs because WinPE tries to compact the offline registry and fails to commit the registry hives back to disk. This problem only happen when you deploy Windows 7 and use WinPE 5.x 32-bit to deploy the image. Resolution is to set this registry value in the boot.wim using DISM or using a 64-bit boot image.

In my case I changed to use the 64-bit boot image, because of Windows 7 x64 deployment. Otherwise you need to edit the 32-bit boot image with the regkey. Very easy solution and no errors seen anymore :-)

Using offline servicing in a server image with multiple indexes

Within ConfigMgr 2012 it's possible to update images with offline servicing functionality. When doing that on server media however, it's possible that multiple indexes are found. When that's the case, updates will be installed on all indexes, which takes a lot of time. In this scenario I'm installing 75 updates on a Windows Server 2012 R2 image with 4 indexes, which are:

-SERVERSTANDARDCORE
-SERVERSTANDARD
-SERVERDATACENTERCORE
-SERVERDATACENTER

When starting offline servicing on this image, a total of 300 updates (4x 75) will be installed. Let's have a look at the ConfigMgr logfile (OfflineServicingMgr.log):

4 images are detected

300 updates are installed

When using DISM however it's possible to remove existing indexes from an image, so offline servicing can do a way better/faster job. This can be done with the following command: DISM /get-imageinfo/imagefile:<path to WIM file>

 
Now that we know which index to keep and which to remove, use the following command: DISM /delete-image /imagefile:<path to WIM file> /index:<index number to remove>

 
In my case I removed 3 indexes, because the only index needed is SERVERSTANDARD. Let's have a look again with: DISM /get-imageinfo/imagefile:<path to WIM file>

There's only 1 index left now. Let's start offline servicing again on this image and have a look at the logfile (OfflineServicingMgr.log):

1 image is detected

75 updates are installed



As you can see this did the trick on my Windows Server 2012 R2 image. Did see another image with 8 indexes before also, which is crazy when using offline servicing. Just use above steps for removing them in the future. Just great isn't it?

Offline servicing is still very handy for updating images easily/quickly, when MS Office is not included in the image.

Source: Microsoft TechNet

Option: /Get-ImageInfo
Displays information about the images that are contained in the .wim, vhd or .vhdx file. When used with the /Index or /Name argument, information about the specified image is displayed, which includes if an image is a WIMBoot image, if the image is Windows 8.1 Update, see Take Inventory of an Image or Component Using DISM. The /Name argument does not apply to VHD files. You must specify /Index:1 for VHD files.

Option: /Delete-Image
Deletes the specified volume image from a .wim file that has multiple volume images. This option deletes only the metadata entries and XML entries. It does not delete the stream data and does not optimize the .wim file.
This command-line option does not apply to virtual hard disk (VHD) files.
/CheckIntegrity detects and tracks .wim file corruption when used with capture, unmount, export, and commit operations. /CheckIntegrity stops the operation if DISM detects that the .wim file is corrupted when used with apply and mount operations.

ConfigMgr Offline Servicing on Volume License media

When using Offline Servicing in ConfigMgr to integrate software updates, it's easy to inject around hunderd updates in a Windows 7 SP1 image (for example). This week I started to inject around 100 updates in a Windows Server 2008 R2 SP1 image. This is however a Volume License media with 8 catalog files available. When selecting from a task sequence you have the following choices: 

 
Trick is however that when using Offline Servicing for this image, it will start the DISM process 8 times also! No way you can choose to inject them on 1 catalog file only. In my case this results in 8 times injecting 110 updates, which will takes lots of time. I rest my case on this one and install updates during Build and Capture, and not using Offline Servicing which I prefer. Too bad there's no option too choose the right Windows edition here, or didn't I find it yet? 

When the DISM process is started already, you can choose to run Configuration Manager Service Manager (ConfigMgr console > Monitoring > Component Status > Start) to stop the responding proces, because of too much time. Hope it helps!