Offline Servicing
Last updated
Last updated
I wanted to take the time to explain all the steps involved with Offline Servicing a Windows Image. This will primarily focus on Windows 10, but the same methods should also be applied to Windows Server 2016.
Offline Servicing is a method that has been used for years to Mount a Windows Image, Apply Patches, and Save the Image. The reason we do this is to save time in our OS Deployments, so we do not have to spend hours applying patches. When Microsoft releases a new ISO, it is fully patched up to the point that they sealed it. In the image below are the Windows 10 Builds with the updated date. Windows 10 1803 is the only version that has been updated this year.
Before getting started, you need to gather the following updates for Windows 10
Latest Servicing Stack
Latest Cumulative Update (Monthly)
Latest Adobe Flash Security Update (Monthly)
If you don't know what a Servicing Stack is, please read a little about that here
https://www.osdeploy.com/osbuilder/knowledge/servicing-stacks.html
Be aware if you do not install the Servicing Stack Update before the Cumulative Update, the CU may not actually install at all since it does not meet its prerequisite. You will not receive a warning or an error when this happens, you will see the CU completed successfully (because it is not applicable since the SSU was not in place)
You absolutely need to understand the Boot WIMs that are used for installing Windows, so here they are.
Boot.wim is located in the Sources directory of your Windows 10 Media. This WIM contains two indexes. Index 1 is WinPE, and Index 2 is the bootable Index, and this is Windows Setup.
The third Boot WIM on Windows Media is located inside the Install.wim at Windows\System32\Recovery\winre.wim. This is the Recovery Environment
When you boot your Windows 10 Media on a computer, it will boot to Sources\Boot.wim Index 2 to start Windows Setup. The image below shows the OS Media and the mounted Setup WIM. As you can see there is a Setup.exe, and they both match. These files are not the complete setup, they just take your parameters and pass them to the setup.exe in the Sources directory.
In the Sources directory setup.exe also exists, and they match as well. On the left is the OS Media Sources, and on the right is the mounted Setup WIM. I wanted to highlight the DISM components as these are required for servicing an image.
This method uses Setup.wim (Boot.wim Index 2). Like files in the Sources directory of this WIM need to be identical to what is on the OS Media Sources.
This uses the Sources directory of the OS Media
Installing an Operating System in MDT will use WinPE (Boot.wim Index 1) as this will take preference over the ADK WinPE.wim. This will require an updated Sources directory in this WIM
This uses WinRE inside that is in the Windows Image
SCCM has its own Boot WIMs. I will work on a solution in then near future for this
Michael Niehaus in this article states that MDT will use the Operating System for WinPE
MDT will look for a matching version of Boot.wim in your imported Operating Systems. This is the version I have in ADK
You can see the difference in sizes in this image BEFORE/AFTER
If you import an updated Operating System with an updated Boot.wim, it will not automatically detect this as valid because the version does not match. To force ADK and MDT to use your updated WinPE, copy your updated WinPE (Boot.wim Index 1) in these locations. For SCCM you should probably do the same with your updated WinPE
This step is important to shrink the internal size if your WIMs. If you do not, your Boot.wim may exceed the size of your Boot Partition.
If you need to enable NetFX3 (you probably do), understand that you must run DISM Image Cleanup first as you will not be able to perform a Cleanup after NetFX3 is enabled due to pending operations.
You can run Get-WindowsCapability on a Mounted Windows Image to validate
If you do not reapply the CU to the Install.wim after enabling NetFX3, your computer will show that the Cumulative Update is needed, and it will be applied in Windows. This defeats the whole point of updating the Install.wim.
The image below shows what the mounted Install.wim looks like after reapplying the CU, so yes, this is required
Exporting the WIMs will reduce the size of the WIMs. If you do not, your Boot.wim may exceed the size of your Boot Partition
To update the Sources directory on your OS Media, you need to perform a Robocopy from your Mounted Setup WIM. You should only update NEWER MATCHING files in your Sources directory.
Repeat this step with your mounted Install.wim. This will ensure that DEVINV is the proper version and prevent issues. For more information about this issue, see these articles
This is what the Sources looks like after performing the Robocopy
If you do not perform this step, Operating System Upgrades will probably fail. Additionally, if you update the Install.wim and not the Sources directory on the OS Media, you will not be able to create an ISO to image from (or a bootable USB). This causes a mismatch as detailed in this link from Microsoft
https://support.microsoft.com/en-us/help/4041170/windows-installation-cannot-find-driver-boot-wim
Windows 10 Upgrades may fail on issues with Application Compatibility. This may happen if the Operating System you are upgrading had received a new Cumulative Update. If the Sources directory in the Upgrade Media has an older version of these files, this will lead to the DEVINV issue I mentioned earlier. The method to ensure that these files are the correct version is to apply the Cumulative Update to the Install.wim and then to Robocopy copy the MATCHING files in the OS Media Sources. Use the image below as a reference for which switches to use.
If you plan on updating your WIMs every month, do not enable NetFX3 as you will not be able to DISM Image Cleanup. This is why I recommend keeping a separate build updated monthly that does not have NetFX3 enabled. Use this as your REFERENCE that you build a secondary Install.wim with NetFX3 enabled.
Install.wim - Servicing Stack and then the Cumulative Update. Enable NetFX3 and reapply CU
WinPE WIM - Servicing Stack and then the Cumulative Update
Setup WIM - Servicing Stack and then the Cumulative Update. Sources will be updated when applying the CU
WinRE WIM - Servicing Stack and then the Cumulative Update
Sources - on the OS Media
Copy the contents of your ISO to a working directory
Mount the Install.wim
Copy WinRE.wim out of the Mount directory
Mount WinRE.wim
Apply Servicing Stack
Apply Cumulative Update
Dism Image Cleanup
Dismount and Save
Export WinRE.wim to another WIM to reduce the size
Copy WinRE.wim back into the Mounted Install.wim
Apply Servicing Stack to the Mounted Install.wim
Apply Cumulative Update to the Mounted Install.wim
Dism Image Cleanup
Robocopy MATCHING NEWER files to OS Media Sources using /b (to bypass Trusted Installer issues)
Dismount and Save the Install.wim
Export Install.wim to a new Install.wim
Replace the Install.wim in the OS Media Sources
Mount Setup WIM
Apply Servicing Stack
Apply Cumulative Update
Dism Image Cleanup
Robocopy MATCHING NEWER files to OS Media Sources using /b (to bypass Trusted Installer issues)
Dismount and Save
Mount WinPE
Apply Servicing Stack
Apply Cumulative Update
Dism Image Cleanup
Dismount and Save
Export WinPE to a new Boot.wim
Export Setup WIM to the same Boot.wim with Bootable switch
Replace the Boot.wim in the OS Media Sources with the updated one
Rebuild ISO using OSCDIMG (ADK)
Copy the Monthly Updated Image to a working directory
Mount the Install.wim
Enable NetFX3 (if needed)
Reapply the Cumulative Update
Perform any additional customizations
Dismount and Save the Install.wim
After importing the matching Operating System in MDT, I can see that it has decided to use this instead of the original WinPE.wim
