This article aims to help readers better understand where devices are pulling their Windows updates from based on the Windows Update registry settings on the local device. We will cover some of the various states the policy can be in, including Windows Server Update Services (WSUS), Microsoft Configuration Manager (ConfigMgr), Intune, and Co-managed devices.
Windows Update Registry Settings are stored in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate registry key
In all scenarios, we need to cover the four different topics:
How the registry keys are controlled
Where the device get its Updates from
What Updates are applied
When these Updates apply
Reviewing the registry values will allow you to quickly identify the client’s state and take appropriate troubleshooting or remediation actions.
With all of the registry settings in this article, it’s important to understand where the policy is controlled. It’s better to modify the policy controlling the registry keys instead of directly modifying the keys. Modifying the registry keys with a policy applied will likely revert back once the policy refreshes again.
This article will not cover Delivery Optimization. We will primarily focus on these updates as they are downloaded from WSUS, ConfigMgr, or Intune.
Windows Server Update Services registry settings:
When utilizing a WSUS Server, Group Policy typically handles WSUS registry settings.
You can control most aspects of how the Windows Update registry settings are set up here.
The Windows Update registry keys can be configured by policy here: Group Policy Management Editor > Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update.
We will use the WSUS server: wsus1.corp.contoso.com
In the WindowsUpdate.log, we can see the MoUpdateOrchestrator handles the download:
More information on how the MoUpdateOrchestrator works can be found here.
In the WindowsUpdate.log, we can see the DownloadManager is utilizing the registry settings controlled by the policy above.
When the system checks in with WSUS, there is a check to see where content is going to be downloaded from; in this case, we download directly from wsus1.corp.contoso.com
To specify which products get installed through WSUS, you need to enable them in Windows Server Update Services > Options > Products and Classifications.
The updates must also be “Approved” either by modifying your “Automatic Approvals” or manually.
Configuring WSUS to automatically download and install the Windows Updates can be configured by Group Policy (notice WSUS Settings is the winning GPO) as well:
The registry settings for Automatic Updates are listed here:HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
The current settings being utilized lined up with the Group Policy applied.
You can automate the updates. However, there are limitations such as maintenance windows, update rings, scheduling reboots, and targeting specific updates. You could, in theory, control most of these options, but it’s a pain to maintain.
Microsoft Configuration Manager registry settings:
Clients will receive their policy from the Client Settings in ConfigMgr when utilizing a ConfigMgr Software Update Point. The Windows Update registry keys can be configured by the policy in Configuration Manager Console > Administration > Client Settings > Software Updates.
In this example, we will use the Software Update Point: cm1.corp.contoso.com
Whether the “Install All” button is pushed or the updates are automatically downloaded and applied, the registry entries tell the client to update from your software update point.
Important: Group Policy Objects will override Client Settings and can cause issues with Software Updates. It’s recommended to disable any GPO modifying the Windows Update policies on the client and allow the Client Settings to take effect. Notice here the Winning GPO is Local Group Policy (ie, the settings are coming from ConfigMgr):
In the WindowsUpdate.log, we can see the download is handled by CcmExec:
In the lab, these are the options that were selected:
The updates and deployments run through various states depending on the deployment settings (forgive my lack of Visio skills). It will look something like this:
Important: A maintenance window check is applied when installing updates; if a maintenance window is not open, the computer will wait for its opening before installing the updates.
All of this is handled in ConfigMgr and not shown within the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU key.
Intune registry settings:
When utilizing Intune, Windows Updates are controlled through Devices > Windows Updates:
For Intune Only devices, the registry keys are somewhere completely different. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update
Unless a Group Policy or an old ConfigMgr policy is applied for Intune devices, HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate is completely blank and doesn’t exist.
All of these registry keys can be modified, however: when the Intune Management Extension checks in again the settings will be reverted. Modifying the settings from the Intune console is always recommended instead of manually changing them.
In the WindowsUpdate.log, we can see the download is handled by the MoUpdateOrchestrator (same as WSUS):
However, this time, the update is being downloaded directly from Microsoft
When it comes to what Updates are going to apply, this depends on the Microsoft Subscription. Update rings, feature updates, quality updates, and driver updates are all applied to different tabs. Prerequisites for Autopatch, including licensing, can be found here.
It looks something like this:
In Intune, you can schedule a delay for these updates, and the reg keys at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update will reflect any policy changes made. However, there are no maintenance windows available. The IME agent checks in once a day and will automatically download and install the updates as needed based on policy.
Understanding PolicyState for Update Policies
Another critical registry key to examine during troubleshooting is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\PolicyState.
This key provides essential details about the active Windows Update policies on the device, including:
PolicySource: Identifies whether the policy is managed by MDM, Group Policy, or another source.
PolicyApplication: Confirms whether the policy has been successfully applied.
Policy Settings and Values: Displays the active policies, their configurations, and potential conflicts.
This is particularly useful for diagnosing devices impacted by updates such as KB4023057, which can reset MDM-managed devices to display as “Managed by Group Policy.” For example, if the device unexpectedly falls under Group Policy control, the PolicySource value will confirm the origin of the applied policies.
Administrators can use this key to quickly identify conflicts or mismatches in update management, making it an essential part of any troubleshooting process
Co-managed registry settings Part 1:
Co-Managment is where things start to get a bit strange. Let’s unpack it. This is where my current workload settings are for my test device.
It’s important to note that the registry changes will take effect on the device once the Windows Update policies are directed to Intune for that specific device. The registry keys remain the same whether the device is part of the Pilot Intune collection or if the slider is set fully to Intune for Windows Update Policies. Using the Pilot Intune setting is ideal for testing, as it only applies to the devices included in the collection under the “Staging” tab.
We have an excellent blog on Dual Scan. The purpose of this blog is to help users quickly identify where updates are coming from just by looking at the registry. However, the SCCM client will leave registry entries behind.
The first thing that usually catches my eye are these options here in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
If the following keys are set to zero, the device pulls these from Windows Update (Intune). According to Microsoft, “If no policies are configured: All of your updates will come from Windows Update.”
Again, going into the registry editor and editing the keys is not recommended. You can do it, but more often than not, the policy controlling these settings will just revert the settings that were manually changed. With the settings above, ConfigMgr is controlling these keys but the gpresult will show “Local Group Policy” as the winning policy.
But on this same device, we can review the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update location and see all of the Intune registry keys.
Looking at the WindowsUpdate.log, we can see the MoUpdateOrchestrator is taking over again.
Co-managed registry settings Part 2
To save myself from confusion later, the Client Policy was changed to Not Allow ConfigMgr to run Software Updates on Clients. After doing so, HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate was completely removed.
When Configuring Co-Management, you lose the ability to run third-party updates (unless you utilize dual scan). First-party (Microsoft) updates will work because they are downloaded directly from Microsoft. If you want third-party updates and plan on migrating workloads to Intune, enable the ClientApps workload for the same collection as your Windows Update policies. This way, if Patch My PC is building your updates in Intune, no loss of third-party patching will occur.
Summary
As you attempt to identify where the updates are coming from, run a group policy to see how these registry values are being controlled.
We’ve explored how Windows Update policies are managed across WSUS, ConfigMgr, Intune, and co-managed devices by understanding the role of registry keys. We’ve seen how to identify where updates are coming from, when they’re applied, and how they’re controlled, all while emphasizing the importance of letting policies govern these settings to avoid conflicts. By focusing on the registry paths, logs, and policy structures, we can effectively troubleshoot and manage updates without introducing unnecessary complications. This knowledge empowers us to maintain a smooth update process tailored to any organization’s needs.
If you’re looking for a faster, hassle-free way to manage application updates, Patch My PC can help. Our affordable solution simplifies app deployment, ensuring your environment stays secure and up to date with minimal effort. Book a demo today to see it in action!
