Page 1 of 1

Cummulative Update reappears

PostPosted: 16.02.2018, 13:58
by snruebes
Hi all,

we use "WUS Offline Update" tool to apply latest MS updates to our reference images - e.g. we applied latest 2018-02 Cummulative Update (KB4074588)
to "Windows 10 Enterprise x64 English 1709" which lifted OS version to Build numver 16299.248 before we sysprep it and create teh WIM using MDT
as it is best practice to keep a reference image offline to avoid issues with updated UWP apps.

So the assumption would be that a new machine which got this image applied is already at the latest patch level.

But when we click on "Check for Updates" in the "Settings" app of such machine it re-detects the same 2018-02 update and also redownloads it.

Then when it comes to installation the Windows Update client or the CU itself recognizes that it is already installed and therfore does not ask for a reboot.

This is bad behaviour, as it creates unnecessary network load.

Therfore our questions:

1) Is this a Windows bug or intended bahaviour or caused by the design of the Windows Update client?

2) Is there a way to avoid this?

3) Can it be caused by our "Cleanup before sysprep" script (see below) which runs in the MDT Task sequence to create teh Reference image?

Additional information:

1. We point our machines to an internal WSUS server to control the OS updates but let the clients download from MS Windows update CDN network directly.
2. We run the "Cleanup before Sysprep" script from ... ge-in-mdt/ ... oreSysprep

to compress our reference image which of course also wipe the "C:\Windows\SoftwareDistribution" folder*

*another source, which seems to do the same things but is based on Powershell is this one: ... o-12de6135

Many Thanks!
Sebastian RĂ¼besamen

Re: Cummulative Update reappears

PostPosted: 16.02.2018, 21:56
by aker
At the moment, there are more than one 2018-02 update for Windows 10 depending on the exact version (e.g. the most recent Servicing Stack for version 1703), which are not part of (:arrow: viewtopic.php?f=7&t=172). The Servicing Stack is handled by a static definition, which at the moment I write this needs updating.
Did you check the KB-number too? And is it the same?

You can watch this topic, where the most recent Servicing Stack updates are listed:
They usually do not take that long to get integrated by a definition update of wsusou.

What do you mean with: detects, it is already installed
Does it report any error? In this case, which error code does it return? Are you able to manually install the msu-file downloaded from the update catalog?

Sometimes the Windows 10 WU-Client gets confused, when it starts detecting updates, updates get installed from another source, and the WU-Client continues whereever it stopped. (This includes wsusou, the Store, the Windows Update Settings Page and Auto-Update.)

And finally clearing SoftwareDistribution is absolutely OK, when the updates were applied successfully (you may even clear before rebooting).

All in all, I would say your Windows image got updated as the version number increased. If you are still unsure, you could compare the result of
Code: Select all
dism /Online /Get-Packages /format:table

before and after WU ran.

I hope I answered all your questions. If I missed one, feel free to respond here.

Re: Cummulative Update reappears

PostPosted: 18.02.2018, 04:52
by boco
Windows Update is a f*cking mess. MS never managed to improve it considerably, and when Windows 10 reared its ugly head it became by multitudes worse.

Re: Cummulative Update reappears

PostPosted: 18.02.2018, 10:05
by snruebes
Hi Aker,

many Thanks for your answer -

as I already said - the Windows update clients downloads the update again at the target machine but when it comes to installation it skips it right after beginning and also does not ask for restart (as it normally does for CU's) - so it does not finally reinstalls it - next time you manually trigger an Windows Update search - this CU also does not reappear.

So there must ne somewhere an information (registry or filesystem) that the CU was already applied which gets wiped by our cleanup of the reference image or through the sysprep step.

Again really annoying - why isn't the Windows able to lock at the build number 16299.248 to see that this update was already applied?

Re: Cummulative Update reappears

PostPosted: 18.02.2018, 23:29
by aker
The update search is based on the Windows Component Store (CBS), which manages the thousands of components Windows is built of. The version number is just one "component".

Again: how much KB/MB does WU (short for Windows Update) really download? I don't think it's more than a little bit.
As far as I know some UUP-components (in my opinion unneeded stuff) don't get updated when installing the MSU- or CAB-file. Might be a reason for WU to show the update as missing (as a few components weren't updates before).
I don't think, that your sysprep-routine is causing this, as I'm slipstreaming my DVDs using DISM and they show the same behaviour. If I were you I would just ignore it. If the version increased and the update shows as installed in "dism /online /get-packages" you're on the safe side. (I'm using the DISM-slipstream method since Windows 7 and never had problems with it until MS introduced UUP.)

Re: Cummulative Update reappears

PostPosted: 19.02.2018, 07:48
by boco
MS has broken many supersedence chains in the past. When such a discrepancy is occurring, WU downloads and "installs" an Express CAB, with just the update metadata in it, to (re-)register the components in the component and SxS store and fill its memory gaps. Such breakages occur frequently when Windows automatic maintenance (which, in turn, runs cleanmgr to purge stale data) does a Windows Update Cleanup. Sometimes, it simply removes too much information about old, superseded updates, and WU needs to re-fetch it.

In extreme cases, you might even see very old updates reappear. Nothing old will be installed, just the metadata re-registered.

Re: Cummulative Update reappears

PostPosted: 19.02.2018, 09:46
by snruebes
Hi boco and aker,

many Thanks for your input - I agree with both of you - and it looks to me that we have to live with this glitch finally - but I want to emphasize, that this is again a very poor desgin / approach from MS and a big mess.

Especially as I see via "Settings => Update and Security => Advanced Options => Delivery Optimization => Activity Monitor" that this newly imaged machine downloaded approx 260 MB for "nothing.

As we using a Technical HUB to prepare up to a few hundred machines per week in one location this can become an issue for the network link in this location although I know that Windows 10 can leverage peer-to-peer download as feature of Delivery optimization.

Besides It confuses our Technicians which monitor the deployment as they think they need to wait until this update is completed to finalize the setup.

Many Thanks for your help!