UPDATE: I’ve added some ConfigMgr / SCCM related details at the end of the blog post.
Over the last few weeks, I had an interesting issue regarding Windows 10 1703 and the Installation of Windows Updating during a Capture MDT Task Sequence.
MDT was configured to install Updates from a locally installed WSUS, which worked for Windows 7 up to Windows 10 1511. I recently started working with Windows 10 1703 and used about the same Capture Task Sequence as for Windows 10 1511. Here I had the issue, that the Reference Computer reaches the first Windows Update Step and runs into a Timeout while searching for Updates. You can leave the Computer pretty much for hours in this state without it doing anything.
What I first tried was pre-applying the latest Cumulative Update before the Task Sequence reaches the Windows Update Step. This was necessary with Windows 10 1607, due to a broken Windows Update Agent in the Vanilla Image. However, here it didn’t change anything unfortunately.
During testing I also had limited success by connecting the Reference Machine directly to the Internet. In addition, when working in a large organization with a complex network, this isn’t really an easy thing to achieve.
The real solution here is to add the two Windows Update related Registry Keys to the Reference Machine, before the Task Sequence reaches the first Windows Update Step. After the last Windows Update Step, we can remove the Keys to restore the Initial Situation for Sysprep and Capture.
As you see, I created a new Group called ‘Add Windows Update Settings’ just before the first Windows Update Step. Add a new ‘Run Command Line’ Step in this Group, name it ‘Set DeliveryOptimization to Bypass’ and specify the following Command Line:
REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization /v DODownloadMode /t REG_DWORD /d 100
Add another ‘Run Command Line’ Step just below the previously created one and name it ‘Set DoNotConnectToWindowsUpdateInternetLocations to 1’. Specify the following Command Line:
REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v DoNotConnectToWindowsUpdateInternetLocations /t REG_DWORD /d 1
Add a ‘Restart Computer’ Step after the above Step.
Create a second Group called ‘Remove Windows Update Settings’ just below the last Windows Update Step.
Add a new ‘Run Command Line’ Step in this Group, name it ‘Remove DeliveryOptimization Registry Value’ and specify the following Command Line:
REG DELETE HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization /v DODownloadMode /f
Add another ‘Run Command Line’ Step just below the previously created one and name it ‘Remove DoNotConnectToWindowsUpdateInternetLocations Registry Value’. Specify the following Command Line:
REG DELETE HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v DoNotConnectToWindowsUpdateInternetLocations /f
Add a ‘Restart Computer’ Step after the above Step.
When now starting the Task Sequence, the Windows Update Step should run through without the above Timeout issue.
Update 2. August 2017: I recently tested the described behaviour with the updated 1703 Media from Late July 2017. I came to the conclusion that the updated media doesn’t change anything and the above described workaround is still needed.
Update 28. September 2017: The same behaviour occurs when using Configuration Manager. Here you can apply same logic as seen above. The Screenshot below is a working example of a Windows 10 1703 OSD Task Sequence in Configuration Manager current branch.
I was just pulling my hair out with this issue and trying to understand why internet connectivity was required to my reference VM to update from WSUS. This fixed my issue. Thank you!
You’re welcome 🙂
Thank you 🙂 works well
Thanks Simon, you got in there _before_ I even got to the hair pulling stage!
Kind regards
Sean
Simon, I owe you SEVERAL beers, Mate. Thank you so much for posting this!
Jonathan
Glad I could help, thanks for the comment. 🙂
Awesome post, you saved my a bucket load of grief. This works when using Configuration Manager instead of MDT.
Nice!
Simon I have tried every solution I could find but nothing seems to work. I hope you can tell me what I am missing.
Setup is: WSUS, MDT 8443 and ADK 1607 on Server 2012 R2, TS to create Windows 2016 reference image. Patched WSUS with both KB3095113 and KB3159706. Did the post install steps. Even installed a Server 2016 with WSUS 4.0 to check is the WSUS server wasn’t working.. Changed the ‘ProtectYourPC’ setting to ‘3’ in unattend.xml of Windows Server 2016.
No matter what I do or install, no Windows Updates are discovered and installed. The reference image will connect to WSUS, but never gets any updates and eventually times out. When creating a Windows 2012 R2 reference image on the same setup, everything works great. During the installation of Windows Server I am adding the CU of December 2016 (even tried June 2017) using a package in MDT. Result is always the same…..no WSUS updates are downloaded. In WSUS I do have Windows Server 2016 updates that need to be installed and in 1 of the runs I did get a list of updates and the server started to download them, but that was one time and I am not able to reproduce that result. There could be a simple explanation but I cannot seem to find it. Using google I found your site and tried to add the reg keys, but also without any success.
Hi Arjan,
You pretty much listed everything that I would have suggested. The WUA Agent in the Server 2016 ISO is in fact broken, which is the reason why you need to pre-apply a CU using Software Distribution Methods. But you already did that though… I can only advice you to reach out to the TechNet forums or CSS.
Best Regards,
Simon
Thanks, this seems to have resolved my problem. Strangely enough, last week everything was fine, and this week it was hanging on “Feature update to Windows 10 Enterprise, version 1703, en-us” (I watched other updates go through fine).
Anyway, thanks for posting! I’d be interested to hear if anyone else suddenly broke this week on that update.
Hi Simon Great solution, but could you explain the Registry edits you are applying? Is this not bypassing the WSUS server altogether?
You are actually bypassing the WUA Setting to directly connect to Microsoft Update.
Hello
Do you have any experience working getting the start screen working during in place upgrade ?
thanks
What exactly isn’t working?
Thanks for making this thread, Simon. It appears that this specific issue is not discussed at all in the MDT technet forums so this saved me some time. Do you have any thoughts on whether new feature updates or cumulative feature updates will work via MDT/SCCM anytime soon? I get the feeling that we’ll have to wait for major version updates to MDT + SCCM for this to happen. Obviously feature/cumulative updates push out fine via WSUS, so I assume that the problem has to do with how MDT/SCCM scripts interact with the WUA agent. Thank you for your time.
Same Problem here with Win10 build 1709 on SCCM without MDT.
Workaround works like a charm. You can find some more Information about “Delivery Optimization in Windows 10” here:
So I think there has to be done some work also.
thanks!
I have add the above to a TS and all the steps leading up to the “Install Software Updates” work but the TS is still failing at that point. The deployment fails with Last Message ID of 11139 Exit Code 16,388 – Any ideas?
Thank you for this Simon.
If someone still have this issue, as I had, I added the latest SSU right before the CU and that was the solution for me