UPDATE - See Part 2 Here
WARNING!!
8/21/2018 - The following steps will enable Dynamic Updates for Windows 10 In-Place Upgrade. If you have not serviced your WIM with THE LATEST Cumulative updates - like today is patch Tuesday and you haven’t updated your WIM with today’s CU, proceed with caution! Your Enabling Dynamic Updates will allow your clients to go to the internet and download the latest Cumulative Update and install it during the upgrade. This is an extra ~800 MB per client from the internet. If this is not desirable, please check out how to offline service your media with the latest Dynamic Updates here.
As I’ve mentioned in previous posts, I’ve been working to get our enterprise to Windows 10 sometime this century. In spite of Microsoft’s best efforts, I’m slowly making headway and hopefully helping you get past some of the issues that we are all encountering.
Background
Michael Niehaus (@mniehaus) blogged about Dynamic Updates in 2017 and went into a great deal of technical info, so I suggest you start there if you want a deeper dive.
The short version is that Windows 10 Setup will go out to Windows Update or WSUS and get Dynamic Updates and Servicing Drivers, then apply them to your OS Install media. This way, you can take advantage of the latest compatibility updates and drivers that will help you have a more successful Windows 10 deployment. So, if you read all the way to the bottom of Michael’s post, you would have seen that SCCM doesn’t support this functionality yet.
Additionally, if you have taken a look at your Software Update options in ConfigMgr, you will notice that you see the same categories and you will see the same updates as Michael mentions are available in WSUS. We have them downloaded and deployed for the testing below.
Target Audience
This info should be helpful to you if:
- You are planning to use In-Place Upgrades for Windows 7 to Windows 10 or Windows 10 (old) to Windows 10 (latest).
- You are using ConfigMgr and use it to manage your Software Updates instead of standalone WSUS (which I highly recommend)
- Your clients will have internet access during their upgrade
- You are OK with clients going out to Windows Update to get updates during their upgrade.
If you meet all of these criteria, please read on.
Testing
All testing was done on Windows 7 x64 and Download and Install Updates is selected via GUI or command line.
Scenario 1
Install Method: Windows 10 Setup.exe GUI
SCCM Client: Installed
Windows Update Agent: Managed by SCCM
Dynamic Update Status: No Updates Found
Results: The client attempts to check for Windows Updates from the internet, but actually only contacts ConfigMgr, which doesn’t return any updates. (WindowsUpdate.log)
Scenario 2
Install Method: Windows 10 Setup.exe GUI
SCCM Client: Not Installed
Windows Update Agent: Managed Windows Update
Dynamic Update Status: Updates Found
Result: The client contacted Windows Update and successfully downloaded Dynamic Updates successfully. (WindowsUpdate.log)
Scenario 3 (Desired)
Install Method: SCCM Task Sequence
SCCM Client: Installed
Windows Update Agent: Managed by SCCM
Dynamic Update Status: No Updates Found
Result: The client attempts to check for Windows Updates from the internet, but actually only contacts ConfigMgr, which doesn’t return any updates. (WindowsUpdate.log and smsts.log)
Note: Dynamically update Windows Setup with Windows Update and Override policy and use default Microsoft Update are selected in the Task Sequence.
Scenario 4 (Hack)
Install Method: SCCM Task Sequence with Hack in place
SCCM Client: Installed
Windows Update Agent: Managed by SCCM
Dynamic Update Status: Updates Found
Result: The client contacted Windows Update and successfully downloaded Dynamic Updates successfully.
Note: Dynamically update Windows Setup with Windows Update and Override policy and use default Microsoft Update are selected in the Task Sequence.
The Hack
Add these commands to your In-Place Upgrade Task Sequence. You will want to add criteria to the Registry entries so that you don’t write new keys if they don’t already exist. You could also be cool and write a script to do all of these steps, I just didn’t have time to write one. Plus, this is easier to debug.
Type: Group
Name: Upgrade the Operating System
Type: Run Command Line Step
Name: Rename Registry.pol
Command Line:
cmd /c "ren c:\Windows\System32\groupPolicy\Machine\Registry.pol Registry.bkp"
Type: Run Command Line Step
Name: Update WindowsUpdate\AU Key
Command Line:
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 0 /f
Type: Run Command Line Step
Name: Update DisableWindowsUpdateAccess Reg Key
Command Line:
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v DisableWindowsUpdateAccess /t REG_DWORD /d 0 /f
Type: Run Command Line Step
Name: Restart Windows Update Service
Command Line:
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -Command "Restart-Service wuauserv"
Type: Upgrade Operating System
Name: Upgrade Operating System
Select your Upgrade media and only check Dynamically update Windows Setup with Windows Update and Override policy and use default Microsoft Update are selected in the Task Sequence.
See The bottom of this post for more info
Type: Group
Name: Cleanup
Type: Run Command Line Step
Name: Rename Registry.pol
Command Line:
cmd /c "ren c:\Windows\System32\groupPolicy\Machine\Registry.bkp Registry.pol"
Type: Run Command Line Step
Name: Rename Registry.pol
Command Line:
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 1 /f
Type: Run Command Line Step
Name: Update DisableWindowsUpdateAccess Reg Key
Command Line:
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v DisableWindowsUpdateAccess /t REG_DWORD /d 1 /f
The end result should be something like this:
Obviously you will have more in your TS, but if you check the Perform Windows Setup compatibility scan without starting upgrade option on the Upgrade Operating System step, you can test quickly without upgrading
What the Hack does
I don’t have any idea, I just work here!! Also, this is what I have deduced by watching logs and such. It could be completely wrong, but the Hack works whether I’m wrong or right 🙂
If you ran through scenario 3 and looked at your smsts.log, at the top of your Install Operating System step, you will see Overiding existing WU policy. This isn’t a command line option in Windows setup, it’s just a registry hack that doesn’t appear to work properly (or maybe it’s just misunderstood). When your client settings are configured to manage Windows Update, these settings come down in the form of registry policies. More specifically, they come down in the c:\Windows\System32\GroupPolicy\Machine\Registry.pol file.
In fact, call your co-worker over and tell them you’re going to do a magic trick. Delete the Registry.pol file then do a Software Updates and Deployment Evaluation Cycle in the ConfigMgr client. Watch their faces as the file magically reappears right before their eyes! Ok sorry. I need to go to sleep!
The Registry.pol file is then added to registry keys at HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. If you delete the registry key then gpupdate /force, the registry key will be recreated. If you update any of these values, the Windows Update agent (WindowsUpdate.log) detects the change and processes it. NOTE: Changes made to the registry entries do not get written to the Registry.pol file. If you change the keys, delete them, then gpupdate /force, you will get the original values back. This is an important thing to note. During the Task Sequence, the whole key is deleted, effectively reverting control of updates back to the Windows Update agent, but since the Registry.pol file is still present, the agents still look at SCCM for updates. I haven’t dug any further, but I suspect these settings are actually in WMI as well. Possibly here: ROOT\ccm\softwareupdates\WUAHandler\CCM_UpdateSource. Looks like more testing in my future!
Once I tracked the processes down, I tried several things. Pre-Deleting the registry keys and/or Registry.pol file caused the Task Sequence to fail since it the settings were missing but were expected to be there. Deleting registry.pol and setting UseWUServer to 0 seemed to be the key, however I found that even though the Windows Update agent would see the changes, ultimately, the service needed to be restarted before it pick up the changes and begin talking to Windows Update.
Next Steps
I have begun a conversation with some of the folks from Microsoft via Twitter and it appears that there may be a supported workaround for this. I’m hoping that this hack is short-lived. Additionally, there’s a UserVoice suggestion that’s been on the list since September 28, 2016 for this functionality to be added to ConfigMgr. Consider voting for it to see if we can get it moved up the priority list. I know that the product team is actively working to improve things, it just takes time.
We’ve never been closer!