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.
Thank you. This is going to save me a lot of time. You rock for posting this.
ReplyDeleteThanks for mentioning! My pleasure ;)
DeleteAwesome thanks!!!!!!!!!
ReplyDeleteMy pleasure!
DeleteHI Henk, I am trying to do the offline servicing of the windows image using sccm 2012 R2 sp1 however when i click on OS image to schedule updates i do not see any available updates. I can see the updates in the all software update.
ReplyDeleteRemember updates must be downloaded first within SCCM to use the offline servicing feature! Guess that will do the trick. Hope it helps!
DeleteHi Henk,
ReplyDeleteAny concerns if we inject 2 CUs in Win10 image at once through offline servicing, for example I'm injecting patches on monthly basis, I missed schedule in December to inject November Cumulative Update for Win10 1703, now I have listed in offline servicing 2 CUs to inject (November and December).
Any concerns that this may fail, I don't want to get into situation to restore .wim file from backup.
Thanks
I know this is an old article but I recently went through this procedure as there are now 11 indexes on our Win 10 WIM, a real pain applying multiple updates across all those indexes, takes forever.
ReplyDeleteAnyway, after removing the extra indexes (we only need Education) I get an error in the Offline Servicing log that reads "WIM::GetWIMImageCount returned code 0x8007000d" and then it fails to go any further and aborts the updates. Any ideas?