Windows Update Uses Unexpected Sources

Use a policy-first check, then confirm the source the Windows Update agent is actually using.

1. Check for Group Policy conflicts
   • On an affected device, open an elevated Command Prompt and run RSOP.
   • Go to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update.
   • If the conflicting setting appears there, Group Policy is applying it.
   • If the policy is labeled Local Group Policy, it was applied during imaging or by Configuration Manager.
   • Modify or limit targeting of the conflicting policy to remove the conflict.
2. Check Configuration Manager client settings
   • In the Microsoft Endpoint Configuration Manager Console, go to Administration > Overview > Client Settings.
   • Review Software Updates settings.
   • If Software Updates is configured there, remove or adjust those settings to avoid conflicts with Windows Autopatch or other Windows Update policy authorities.
3. Determine the effective update authority per category A single default-service check is not reliable when scan source or Windows Update client policies are configured. Windows can route different update categories differently, such as Driver, Feature, Quality, and Other. Check the resolved policy state that the Windows Update agent commits after policy refresh. This is the most reliable view because it reflects:
   • Group Policy versus Intune arbitration
   • the UseWUServer requirement
   • what the agent actually honors, not just what was authored
   For the per-category values:
   • 0 = Windows Update
   • 1 = WSUS
   Also inspect:
   • the primary switch UseUpdateClassPolicySource
   • the four SetPolicyDrivenUpdateSourceFor* values
   • WSUS and Dual Scan configuration
   • MDM PolicyManager state on co-managed devices
   If only some category values are set while UseUpdateClassPolicySource = 1, the device has a partial configuration and may scan against unexpected sources.
4. Check MDM PolicyManager on co-managed devices
   • Inspect values under \current\device\Update.
   • These indicate that an MDM authority such as Intune, Windows Autopatch, or a third-party MDM configured Windows Update policy.
   • If multiple providers are present, identify the winning provider for each conflicting value.
5. Restart the Windows Update service after policy changes After changing a Windows Update policy, restart the service so the agent reloads policy:

      Restart-Service wuauserv
   

   Then trigger a new scan. Policy changes do not take effect until the agent reloads them.
6. Confirm the actual update source in use Run these commands in an elevated PowerShell session:

      $MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
      $MUSM.Services
   

   Interpret the output as follows:
   • Microsoft Update / OffersWindowsUpdates: True = Microsoft Update
   • Windows Server Update Service / OffersWindowsUpdates: True = WSUS
   • Windows Update / OffersWindowsUpdates: True = Windows Update online
   • DCat Flighting Prod / OffersWindowsUpdates: True = feature updates from Windows Update
7. Use WindowsUpdate.log to verify what each scan or download used Generate the log with:

      Get-WindowsUpdateLog -LogPath "$env:USERPROFILE\Desktop\WindowsUpdate.log"
   

   This is especially important in co-managed environments because it shows the service actually used for each scan or download.
8. Watch for old or conflicting policy models Windows update behavior can be affected when both Group Policy and MDM settings are configured.
   • For Windows updates, Group Policy takes precedence over MDM.
   • If a newer policy is set without disabling an older similar policy, devices can show conflicting behavior and use unexpected sources.
9. If Configuration Manager versions are involved, check for known scan source behavior Some Configuration Manager versions wrote scan source values differently. In particular:
   • 2111 wrote category values but not the primary switch, so they had no effect.
   • 2303 + KB 25073607 started setting UseUpdateClassPolicySource = 1, making category routing effective.
   • 2403 stopped writing category values but did not remove existing ones.
   • 2503 HFRU or 2509, with KB 36495448 stops touching scan source policies on co-managed devices and cleans up partial state once.

A practical troubleshooting flow is:

1. Run RSOP to find Group Policy conflicts.
2. Check Configuration Manager Client Settings > Software Updates.
3. Inspect resolved Windows Update policy state, including UseUpdateClassPolicySource and all four SetPolicyDrivenUpdateSourceFor* values.
4. Check \current\device\Update for MDM PolicyManager ownership.
5. Restart wuauserv and rescan.
6. Run $MUSM.Services and review WindowsUpdate.log to confirm the source actually used.

• Conflicting configurations
• Windows Update issues troubleshooting
• Integrate Windows Update client policies with Configuration Manager
• Integrate Windows Update client policies with Configuration Manager
• Policies for update compliance, activity, and user experience