Using Dynamic Update with WSUS to install Windows 10 feature updates
When you install Windows 10 using SETUP.EXE, or any time you install a new feature update either using SETUP.EXE from media or installing via the Windows Update agent, the installation process will attempt to grab a set of additional “stuff” to make the installation process go as smoothly as possible.
The simplest way to see all of this work: Take a virtual machine running Windows (any applicable version or SKU). Make sure the machine isn’t joined to a domain (you don’t want WSUS polices to get in the way). Then make the task harder by installing some language packs manually using the Settings app. Navigate to Time & language –> Region & language and then add one or more language packs. (It’s best doing this before patching the OS, since installing a language pack will require reinstalling the latest cumulative update.)
It’s easiest to kick off an upgrade manually using Windows 10 1703 media. Insert the ISO, or use an extracted copy, and run “SETUP.EXE /AUTO UPGRADE”. Once the upgrade is complete, take a look at the C:\WINDOWS\PANTHER\SETUPACT.LOG file to see what happened. Search for “DU Client Application Information” to find all the dynamic update checks. Here’s an example, shortened some to remove some of the noise:
2017-09-29 21:05:31, Info SP DU Client Application Information
…
2017-09-29 21:05:31, Info SP Executing download operation: Download Language Pack Dynamic Updates
…
2017-09-29 21:05:31, Info SP Searching for dynamic updates
2017-09-29 21:05:31, Info SP Update types:
2017-09-29 21:05:31, Info SP Component updates
2017-09-29 21:05:31, Info SP Category IDs:
2017-09-29 21:05:31, Info SP 6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
…
2017-09-29 21:05:31, Info SP 1 updates were found
You should see a few of them:
- Setup updates (category e4b04398-adbd-4b69-93b9-477322331cd3)
- Critical dynamic updates
- Component updates (category e4b04398-adbd-4b69-93b9-477322331cd3)
- Driver updates (category e4b04398-adbd-4b69-93b9-477322331cd3)
- OS updates
- Component updates (category abc45868-0c9c-4bc0-a36d-03d54113baf4)
- Driver updates
- Driver updates (categories 405706ed-f1d7-47ea-91e1-eb8860039715, 34f268b4-7e2d-40e1-8966-8bb6ea3dad27, 0ba562e6-a6ba-490d-bdce-93a770ba8d21, 06da2f0c-7937-4e28-b46c-a37317eade73)
- Language pack updates
- Component updates (category 6111a83d-7a6b-4a2c-a7c2-f222eebcabf4)
That should raise at least one question: What are those category IDs? Well, it turns out that they aren’t really categories at all, at least not in WSUS terminology. Instead, they map to “products.” If we get a list of the products from WSUS using the “Get-WsusProduct” PowerShell cmdlet (available on Windows Server 2016), you can see these items for Windows 10:
Title ID
----- --
Windows 10 and later drivers 05eebf61-148b-43cf-80da-1c99ab0b8699
Windows 10 and later upgrade & servicing drivers 34f268b4-7e2d-40e1-8966-8bb6ea3dad27 Windows 10 Anniversary Update and Later Servicing Drivers bab879a4-c1af-4b52-9617-0f9ae1286fb6
Windows 10 Anniversary Update and Later Upgrade & Servicing Drivers 0ba562e6-a6ba-490d-bdce-93a770ba8d21
Windows 10 Creators Update and Later Servicing Drivers cfe7182c-14a0-4d7e-9f5e-505d5c3a66f6
Windows 10 Creators Update and Later Servicing Drivers f5b5092c-d05e-4eb1-8a6a-919770378ff6
Windows 10 Creators Update and Later Upgrade & Servicing Drivers 06da2f0c-7937-4e28-b46c-a37317eade73
Windows 10 Dynamic Update e4b04398-adbd-4b69-93b9-477322331cd3
Windows 10 Feature On Demand e104dd76-2895-41c4-9eb5-c483a61e9427
Windows 10 GDR-DU LP 6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
Windows 10 GDR-DU abc45868-0c9c-4bc0-a36d-03d54113baf4
Windows 10 Language Interface Packs 7d247b99-caa2-45e4-9c8f-6d60d0aae35c
Windows 10 Language Packs fc7c9913-7a1e-4b30-b602-3c62fffd9b1a
Windows 10 LTSB d2085b71-5f1f-43a9-880d-ed159016d5c6
Windows 10 S and Later Servicing Drivers c1006636-eab4-4b0b-b1b0-d50282c0377e
Windows 10 a3c2375d-0c8a-42f9-bce0-28333e198407
I highlighted all of the matching items from the SETUPACT.LOG list – they line up nicely (well, except for one of the driver ones, but we’ll leave that mystery for another time). Some of you asked what these categories were for when they showed up in WSUS – now you know. Originally, if you selected these products in WSUS, you never saw any updates show up for them. But that’s no longer the case – some of these will have something in them.
But before we enable those, it’s useful to do one more test: Do another upgrade, but this time, point the machine at a WSUS server. (You can do this via local GPO if you want to keep your AD domain out of the way.) Afterwards, again look at the “DU Client Application Information” sections. Here’s one example (again cutting out some of the noise):
2017-09-29 23:30:10, Info SP DU Client Application Information
…
2017-09-29 23:30:10, Info SP Executing download operation: Download Language Pack Dynamic Updates
…
2017-09-29 23:30:10, Info SP Searching for dynamic updates
2017-09-29 23:30:10, Info SP Update types:
2017-09-29 23:30:10, Info SP Component updates
2017-09-29 23:30:10, Info SP Category IDs:
2017-09-29 23:30:10, Info SP 6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
…
2017-09-29 23:30:10, Info SP No updates to download. Leaving...
And that illustrates the problem: When your devices point to WSUS, they can’t get the needed packages for dynamic update to work, so it doesn’t do anything – no patches, no drivers, no language packs, no updated compatibility information, etc.
OK, so now let’s go back to WSUS and enable the categories highlighted above. Once you do that and synchronize, you’ll see a bunch of new updates are found. If you look at the “All updates” view sorted by the arrival date descending, you can see all of them in the list. But I prefer to create a better view. Right click on “Updates” and choose “New update view". Choose “Updates are for a specific product”, and then select the products highlighted above:
Select the new view, and change the criteria at the top to “Any Except Decline” and “Any,” then refresh to see the full list. These are all the updates that dynamic update could seek out. If you add the “Classification” column to the list, you can see that there are critical updates, security updates, and updates, and there are lots of language packs and related language packages in the list. Also notice that there are no drivers, as those aren’t published to WSUS. (That’s probably a good thing, as there would be lots of them.)
Now let’s take the next step: Select all of those items and approve them for “All computers” and for “install.” Make sure your server has sufficient disk space, that’s a lot of language packs.) That will take a while, first to approve the updates, and then to download all the needed stuff. A good time for a lunch/dinner/weekend break, a stroll through the park, etc.
Once everything is downloaded, we’re ready to try again, upgrading from Windows 10 1607 (with an extra language installed) to Windows 10 1703. Again, I’ll use media and kick off the upgrade using “SETUP.EXE /AUTO UPGRADE”. After it finishes, the SETUPACT.LOG again provides a view into what happened, in this case for language packs:
2017-09-30 11:17:07, Info SP DU Client Application Information
…
2017-09-30 11:17:07, Info SP Executing download operation: Download Language Pack Dynamic Updates
…
2017-09-30 11:17:07, Info SP Searching for dynamic updates
2017-09-30 11:17:07, Info SP Update types:
2017-09-30 11:17:07, Info SP Component updates
2017-09-30 11:17:07, Info SP Category IDs:
2017-09-30 11:17:07, Info SP 6111a83d-7a6b-4a2c-a7c2-f222eebcabf4
…
2017-09-30 11:17:08, Info SP 1 updates were found
Yeah! And we can confirm that with PowerShell by running “Get-WindowsCapability -online” to see what’s installed:
Name : Language.Basic~~~en-US~0.0.1.0
State : Installed
Name : Language.Basic~~~de-DE~0.0.1.0
State : Installed
Name : Language.Handwriting~~~en-US~0.0.1.0
State : Installed
Name : Language.Handwriting~~~de-DE~0.0.1.0
State : Installed
Name : Language.OCR~~~en-US~0.0.1.0
State : Installed
Name : Language.OCR~~~de-DE~0.0.1.0
State : Installed
Name : Language.Speech~~~en-US~0.0.1.0
State : Installed
Name : Language.Speech~~~de-DE~0.0.1.0
State : Installed
Name : Language.TextToSpeech~~~en-US~0.0.1.0
State : Installed
Name : Language.TextToSpeech~~~de-DE~0.0.1.0
State : Installed
Name : Language.UI.Client~~~en-US~
State : Installed
Name : Language.UI.Client~~~de-DE~
State : Installed
That looks good, two languages (English and German) with all the needed language pieces in place. (That’s a separate conversation that I think I’ve blogged about before – you need several components to have full support for a new language.)
Another difference that can be seen: Even though I’m using the original Windows 10 1703 ISO (build 15063.0), the upgraded machine has a later patch installed:
That’s not the absolute latest build (15063.540 installed, latest patch would be 15063.632 at the time of writing), but it is the expected result: The dynamic update process doesn’t necessarily grab the latest update, it grabs the latest cumulative update tagged as a dynamic update. So it should be no big surprise that when you check for updates after upgrading, it finds updates to install:
But that does illustrate one other important point: All of those dynamic updates that I approved are only used by the SETUP installation process (again, whether initiated from media, from WSUS, etc.). You’re not going to suddenly see all of your machines trying to install lots of language packs after you approved them in WSUS.
Thanks to Sudhagar Thirumoolan for getting the needed packages published to WSUS to make this work, and to former WSUS PM Steve Henry for repeatedly saying this was possible.
Some of you might be thinking “what about ConfigMgr.” The challenge there is that you would need to go through the same WSUS steps to make this work with ConfigMgr (task sequences or Windows 10 servicing), and the ConfigMgr team doesn’t support that sort of manipulation.
In the future, we’ll be making some changes to the way these components are published, as part of the Unified Update Program work. Once that’s done, then this will be much easier: Everything needed will be part of the same package bundle. As mentioned at Ignite this week, that bundle will be large (since it contains language packs, cumulative updates, features on demand, and more), but clients will be smart enough to only download what they need. Stay tuned for more on that.