Prove which service owns Windows Update on a co-managed device

When to Use This Guide

Use this guide when a co-managed Windows device reports an Intune update ring assignment, but the client still scans a Configuration Manager or WSUS source.

Typical signs:

• Intune shows the ring as assigned or succeeded, while the device installs from the software update point
• WUAHandler.log still names a WSUS URL after the Windows Update workload slider moved to Intune
• Pilot devices behave differently from co-managed production devices in the same ring
• Moving the slider did not change scan source on the next policy cycle

Do not start by deleting the Intune ring. First prove which management plane currently owns Windows Update policy on that device.

The handler and scan excerpt in Step 2 is an illustrative reference example checked against Microsoft documentation, not a lab capture. UseWUServer and WUServer are not set in the example, so it shows the handler and scan path, not which service owns the scan source.

For ring deferral diagnosis after Intune actually owns the workload, use Windows Update for Business deferral not applying. For the licensing and provisioning boundary, use Intune or Configuration Manager.

Scope and Assumptions

This guide is written for co-managed Windows 10 and Windows 11 clients that still have the Configuration Manager client installed.

It assumes:

• Co-management is already enabled
• You can read co-management properties, client settings, and the device's local update policy
• You will change workload ownership only on a pilot collection

Microsoft documents seven co-management workloads. Operating system deployment is not one of them. Changing the Windows Update slider does not retire task sequences, boot media, or Autopilot.

Primary sources:

• Co-management workloads
• How to switch Configuration Manager workloads to Intune

What the slider does not prove

Record the pilot collection, the current Windows Update workload value, and the expected scan source before you change anything.

What evidence you must capture

Capture these on one affected device before anyone moves a slider, edits a ring or deletes a deployment. Each item answers a different question, and none of them is replaced by a green status in either portal.

• Co-management properties (console): the Windows Update workload value and the pilot collection it points at, plus proof the device is a member of that collection. This is what the site intends; it is not proof the client has received it.
• CoManagementHandler.log in C:\Windows\CCM\Logs: the workload state the client has actually received from the site. If this still shows Configuration Manager owning Windows Update, the Intune ring is not in charge yet, whatever Intune reports.
• WUAHandler.log in the same folder: the update source the ConfigMgr client registers with the Windows Update Agent when it searches for updates. A software update point URL here means ConfigMgr is still driving scans.
• UseWUServer under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU: the effective local policy. 1 tells the Windows Update Agent to use the server named in WUServer; absent or 0 means it is not being pointed at a WSUS server by policy.
• WUServer (and WUStatusServer) under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate: the configured WSUS or scan server URL. Compare it with your software update point FQDN. A URL that is not your SUP points to a Group Policy object or another tool, not ConfigMgr, setting scan source.
• Time of capture and last policy cycle: note when you read each item. A log read before the client's next policy cycle cannot prove a slider change failed.

Read the logs and registry directly and record what they say. Do not paraphrase them into the ticket as "looks fine"; the value or URL itself is the evidence.

Step 1: Record the co-management authority

In the Configuration Manager console:

1. Open Co-management properties.
2. Note the Pilot collection used for the Windows Update workload.
3. Note whether the workload is Configuration Manager, Pilot Intune, or Intune.
4. Confirm the device is a member of that pilot collection, not only an Intune device group.

Microsoft's workload list is compliance policies, Windows Update policies, resource access policies, Endpoint Protection, device configuration, Office Click-to-Run apps, and client apps. Do not treat task-sequence OSD as an eighth slider.

On the device, confirm the ConfigMgr client is still present and talking to the site:

Get-Service CcmExec, wuauserv, usosvc |
    Select-Object Name, Status, StartType

Expected output shape:

Name     Status  StartType
----     ------  ---------
CcmExec  Running Automatic
wuauserv Running Manual
usosvc   Running Manual

If CcmExec is missing, this is not a co-management ownership problem. Treat it as an Intune-only or orphaned-client problem.

Step 2: Read the client logs that name the source

Default log folder:

C:\Windows\CCM\Logs

Look for the Windows Update workload value and the scan URL. A successful Intune ring assignment in the portal is not a substitute for WUAHandler.log naming Windows Update rather than the software update point.

$LogRoot = "C:\Windows\CCM\Logs"
$Patterns = @(
    "Windows Update",
    "WUAHandler",
    "WSUS",
    "scan",
    "workload"
)

Select-String -Path "$LogRoot\CoManagementHandler.log", "$LogRoot\WUAHandler.log" `
    -Pattern $Patterns -ErrorAction SilentlyContinue |
    Select-Object Path, LineNumber, Line |
    Select-Object -First 40

Expected output shape:

Path       : C:\Windows\CCM\Logs\WUAHandler.log
LineNumber : <line>
Line       : <timestamp> <scan source or WSUS URL>

Do not invent timestamps or success rates from this example. Use the lines the client actually wrote.

Reference example (illustrative)

Illustrative excerpt, checked against Microsoft documentation for the co-management and scan log sequence. CoManagementHandler shows the device provisioned, AutoEnroll true, merged capabilities 8223, and the machine already enrolled with MDM. The WUAHandler lines are dated 09-05-2026 and show a scan that failed with 0x80240438, then a later scan that completed successfully. UseWUServer and WUServer are not present in this example, so it does not prove scan-source ownership by itself.

Example excerpt, CoManagementHandler:

Example excerpt, WUAHandler:

Step 3: Check local scan-source policy

Intune rings control deferral and deadlines only when the device is scanning Windows Update. If Group Policy or ConfigMgr client settings still set UseWUServer, the ring is not the active decision point.

$GpWuPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$GpAuPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"

foreach ($Path in @($GpWuPath, $GpAuPath)) {
    Write-Output ""
    Write-Output "[$Path]"
    if (Test-Path $Path) {
        Get-ItemProperty -Path $Path |
            Select-Object WUServer, WUStatusServer, UseWUServer, DisableDualScan |
            Format-List
    } else {
        Write-Output "Not present"
    }
}

Expected output shape:

[HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
WUServer        : http://<software-update-point>:8530
UseWUServer     : 1
DisableDualScan : <value or blank>

If UseWUServer is 1 on a device that should be on Windows Update for Business, the workload move is incomplete or another policy is rewriting scan source.

Also check ConfigMgr software update client settings for that device: scan source, deployment package availability, and whether a maintenance window is hiding an otherwise successful scan.

Step 4: Separate workload transition from update deployment

Moving the Windows Update workload to Intune does not:

• Cancel an already downloaded ConfigMgr software update
• Remove WSUS registry values written by Group Policy
• Change feature-update target-release policy from a GPO
• Prove that an Intune quality update expedite will apply

Do one thing at a time on the pilot:

1. Confirm collection membership.
2. Move only the Windows Update workload to Pilot Intune.
3. Wait for the ConfigMgr client policy cycle.
4. Recheck CoManagementHandler.log and WUAHandler.log.
5. Only then judge the Intune ring.

Microsoft's switch-workloads guidance is the authority for the slider behaviour. Do not treat a single portal success state as the end of the transition.

Step 5: Validate and roll back

Validation on one pilot device:

• CoManagementHandler.log shows the Windows Update workload value you set
• WUAHandler.log names the scan source you expected
• Local UseWUServer matches that source
• The next quality or feature update offer comes from the intended service

Rollback:

• Return the Windows Update workload to Configuration Manager for the pilot collection only
• Do not rebuild the device
• Do not delete the Intune ring to undo a ConfigMgr scan-source problem
• Leave Office click-to-run, compliance, and endpoint protection workloads unchanged unless they were part of the same approved change

Sources

• Co-management workloads
• How to switch Configuration Manager workloads to Intune
• Related AdminSignal guides: WUfB deferral diagnosis, Intune vs ConfigMgr, Configuration Manager hub

Correction record

24 October 2026 — Relabelled: The CoManagementHandler and WUAHandler excerpt in Step 2 is now presented as an illustrative reference example checked against Microsoft documentation. It was previously labelled as a home-lab capture; it is not a lab-tested result.

26 September 2026: Added CoManagementHandler and WUAHandler example lines. The handler shows the device provisioned, MDM enrolled, AutoEnroll true, and merged capabilities 8223. WUAHandler shows scan failure 0x80240438 and a later successful scan. UseWUServer and WUServer are not set in the example.