—– Feel free to read to better understand Dynamic Updates, then do yourself a favor and use OSDBuilder —-
UPDATE 7/23/19 – MS just made Dynamic update for 1809 Available via WSUS again. (Before they were only available via MS Updates) More info about that, and a great read about Dynamic Updates HERE
UPDATE: 8/20/18 – Adam Gross (@AdamGrossTX) added more info and explain even more! That guys is awesome, really nice walk through on how to do it with a script to automate! Check it out HERE
UPDATE: 8/17/18 – Heard back from MS. Rest of those Dynamic Updates need to be applied offline to your Build Media, they are NOT included in the monthly CU. (Read full article for context)
Dynamic updates, what are those things? Well, as Microsoft says “With Dynamic Update, if you start a computer from an existing operating system (for example, Windows 8), and then run Setup from that operating system [IN PLACE UPGRADE], Setup [Windows 10 Upgrade Setup] can check for new Setup files, including drivers and other files.” You can enable it in your TS on the Upgrade OS step: (yes, you want to do this if you have bandwidth, way more info HERE, Thanks Adam)
As explained in that article, many organizations disables dynamic updates so it doesn’t go out to the internet to get that data, and even prevent it from pulling down from WSUS. Why block this, bandwidth. If you have several computers on a small WAN link all trying to go out to Windows Update or even a remote SUP to pull down this content, it could bring down that remote office.
But that information in the dynamic update is very valuable, and can improve success rates for Windows 10 upgrades, so how can we incorporate the dynamic update content directly to the windows upgrade media source package? Pretty easy actually… download the KB, extract it, and copy it into your package.
Here’s how I was able to find the Dynamic Update KB (If anyone knows a better way, please let me know).
Look through your Software Updates in CM Console.
So you don’t see Dynamic Updates when you search? Make sure you enabled that product in “Software Update Point Component Properties”
Ok, so now that you know how to find it, grab the download URL from the properties & Download.
Once downloaded, go ahead and extract it to a temp location.
expand KB123456.cab f:* C:\Temp\KB123456
You’ll now see the extracted Files:
If you take a look at it, you can see that the version is updated to a much higher level than the original. devinv.dll, look familiar? It should.. if you don’t update this, if you’re doing upgrades to 1709, it’s probably caused you trouble. Detailed info from CTGlobal’s Blog
So now, you just copy those files to your Windows Upgrade Media Package into the sources folder and update (overwrite) the original files. (really recommend you do this in your Pilot Package first, then once tested, apply the changes to your Prod Package)
Congratulations, now you’ve got the Dynamic Update goodness built into your Windows Update Media.
Sorry, I have no automation to do this monthly, it’s a bit of leg work, but worth it. (or just check that box in your TS if you can without melting your network)
If you’re like me, you’re wondering, what about all those other dynamic updates, they aren’t superseded, so what are they? I went ahead and extracted them all, they contained drivers, manifests and many other random files. I did not add them into my sources folder, as it felt to me like they belonged in various sub-folders, but when I extracted them, they didn’t extract in a way I’d feel comfortable with just adding into my sources folder. I’ve got a dialog open with MS about it, and I’m hoping they explain how I can incorporate those other ones as well. I’ll update this post once I know more… Updated…
UPDATE: 8/17 – Heard back from MS. Rest of those Dynamic Updates need to be applied offline to your Build Media, they are NOT included in the monthly CU.
Posted on GARYTOWN.COM
Nice work, as always, Gary.
Our WSUS has 19 updates with title containing Dynamic Update for Windows 10 Version 1709 for x64 dating from 2017-11. Windows Update Catalog shows that only KB4135058 and KB4294595 are superseded. Does this mean all are needed? And is it only the last one that gets extracted and copied and all the rest injected offline using DISM?
Anything Superseded, just skip. I setup an ADR for each 1709 and 1803 that grabs just the Dynamic Updates for each, that are for x64, and not superseded. Adam has a nice write up on how to install them, I added the link to the top of my blog.
Hi, I use the schedule update option in the SCCM Console – and choose that UPD – does this do the same thing or just updates the WIM file itself within the media source? I’m wondering if I should be using this process or just using that process build into the Console now.
If you’re using the Console to Offline Service your WIM, you’d only be updating the WIM, it would not actually patch your Upgrade Media you’d have to do that manually. I’d HIGHLY recommend using OSDBuilder instead using the built in update feature. Also, you’d never want to service the same WIM over and over, you’d want to revert back to the original media each time you service. All the more reason to use OSDBuilder.
Thanks. That really helps. The console version did only look like it was doing the wim. Does that OSDBUILDer actually do both? Do I only need to do what you’ve indicated here or do I actually need to also update the WIM in the that source for my “Operating System Upgrade Packages”?
I’m trying to get around the following issue which seems to imply I need the upgrade itself to have the patch. I tried the manual methods here and it fails with access denied, so I’m thinking I should go down this route. https://support.symantec.com/en_US/article.TECH252314.html
I’m hoping that if I go through trouble of the above and put the LCU in there, it will have this patch and the SEP will not acl’d incorrectly.
The latest Media from VLSC should include the patches required for the SEP issue. Then if you patch it offline and apply what’s available, you should be fine. Otherwise you should be able to script either work-around and place it in your TS to run after the new OS is installed. Would be really nice if they would just provide a PowerShell script for both Work-arounds. You might be able to request that from their support. But the updated March Media should include that patch.
I had it working but it turns out EVEN if I do the reACL in the TS it fails unless we change the policies for SEP. I’ll see if someone can check VLSC (we use pro not sure if that matters).
When you say OTHERWISE – When you say script either workaround – are you saying I should be able to install the upgrade media – then call the LCU patch directly after that in the TS and it would work? Or are you saying to expand the LCU patch and copying over the current SCCM source files we use for the OS upgrade package?