Lately I was stopped by a «new» bug while updating my Hydration kit. As I wanted to deploy the latest security updates with Windows Server 2019, the process always failed unless Servicing stack update was removed from the list of packages. After searching the web, I found this post with the same issue on Server 2016, here are the common symptoms that have been observed:
- MDT is used to deploy a bunch of staged updates (using the “Apply Patches” step) to a Windows Server SKU.
- One of the packages is a servicing stack update (SSU).
- When the task sequence fails, the DISM logs reports inability to copy a file from one of the packages because it is missing.
-If the SSU is deployed alone or in a separate DISM command instance, it works!
Want to know how to solve this? the answer will be given within the next few minutes, but first, a few words on the “Why” it happens.
Why
MDT leverages the offline servicing technology to apply KB to an image (patches are applied over a non running Windows).If MDT is plugged to a WSUS server or Microsoft Update, it uses a more traditional servicing approach where KB are applied on a running Windows.
In our case, MDT uses offline servicing whish works roughly like this during the WinPE phase:
- MDT retrieves the list of staged updates and filter out the unnecessary one.
- It references each package in an Unattend.xml file.
- When the image is applied to the disk, a DISM /Apply-Unattend command is run using the unattend.xml file.
- All the packages referenced in the xml file are applied in the same “DISM session”.
As explained before (Many thanks to Tony D Gedge), embedding SSU and other updates in the same session fail with Windows Server. The way MDT works make it impossible to separate SSU from other updates so at that point we are stuck!!!!... unless…
Solution
To make SSU applied separately from other KB, we first need to make two different profiles:
One for SSU called PACKAGE-Server2019-SSU.
The other for all the other patches called PACKAGE-Server2019.
In the task sequence, we will create an “Apply package” step for both profiles at the end of the Preinstall section.
Of course, those steps won’t do the trick unless the underlying ZTIPatches.wsf script is modified. Obviously, the change is super light and will create Unattend0.xml, Unattend1.xml and so on each time the “Apply package” step runs in the Task Sequence.
The edited version of ZTIPaches.wsf can be downloaded here and should replace the original in the Scripts folder of your deployment share.
Now that SSU and other patches are in separate files, we need to further edit MDT to take those new files into account!
Unattent.xml file is applied by LTIApply.xml script. To make it support our new files, the DISM /Apply-Unattend part of the script needs to be shifted into a loop that process all the available unattended files one by one. Simple and nice, nothing else is needed!
The edited version of LTIApply.wsf can be downloaded here and should replace the original in the Scripts folder of your deployment share.
Now that support for multiple unattend.xml file is enabled, installation of SSU and other updates will work seamlessly:
In BDD.log file, you can see that unattend0.xml is created with the SSU package profile (PACKAGE-Server2019-SSU):
And unattend1.xml is generated with the other patches profile (PACKAGE-Server2019):
Stepping dawn into the log, you will see the first XML beeing applied:
And then, the second one:
OS patched successfully! Mission accomplished!!!!
Note about Windows 10
Similar tests were conducted on Windows 10 1903 without failure, so it seems that Windows 10 and Server are very different animals regarding SSU updates… until time makes this sentence wrong… See ya.