Troubleshooting Co-Management wufb Workloads and the WMI StateMsg Namespace



Organizations are continually seeking more efficient ways to manage and deploy Windows updates. Moving Windows Update for Business (WUfB) workloads from SCCM to Intune is a popular choice for achieving modern management and ensuring seamless updates.

However, this migration process can sometimes reveal unexpected challenges.

In this blog post, we'll explore an interesting issue that I have faced during the migration of WUFB workloads from SCCM to Intune.

This issue pertained to client devices experiencing difficulties with WUfB workloads, as indicated by non-compliant error messages in the logs. We'll go into what "non-compliant" means in this context and discuss how to resolve the problem.

Understanding WUfB Workloads:

Before we dive into the troubleshooting process, let's first establish some background information. WUfB workloads are an essential part of modern management for managing windows updates using Intune.

Once workloads are moved to a pilot collection or Intune, it is expected that client devices receive policies and process these workloads.

Before moving the wufb workloads to intune, client has already received some workloads as stated below.


Incase you have assigned the wufb ring policies to the devices that are not moved with wufb workloads successfully, the wufb ring status shows not applicable.


The Challenge:

After the wufb workload is moved to intune, the Intune-managed workloads hadn't changed as expected. Upon investigating the client logs, specifically the "CoManagementHandler.log," discovered the following error message:

"Failed to process SET for assignment (ScopeId_B2BF025F-3D87-43A5-8125-449D55F8CCA6/ConfigurationPolicy_82e8efbb-1955-4890-ac6e-266c77edce38 : 7). Error 0x80041013."

The error code "0x80041013" translates to a provider load failure within Windows Management Instrumentation (WMI).

To know more details about the co-management policies , there is another log "SettingsAgent.log," which provides information related to the enforcement of specific applications, records the orchestration of application group evaluation, and details of co-management policies.

The information retrieved from the "SettingsAgent.log" is below.

"Id = {DE9AE64E-340D-4C32-A48D-848AE4B0C3AB}; ClientMachine = APS-567GHA48 NT AUTHORITY\SYSTEM; ClientProcessId = 4328."

It also contained the following entry:

"Start IWbemServices::ExecQuery - root\ccm\StateMsg : SELECT * FROM CCM_StateMsg WHERE TopicType='401' AND TopicID='ScopeId_B2BF025F-3D87-43A5-8125-449D55F8CCA6/Baseline_db1d21e6-b445-4ad8-9ca8-7beea9c82909/4' AND UserSID=''; PossibleCause = Unknown."

This log entry indicated an issue querying data from "StateMsg."



The root of the problem appeared to be a corrupted "StateMsg" namespace. To fix this , I have attempted to compile "StateMessageProvider.mof" using the following steps:

  1. mofcomp C:\Windows\CCM\StateMessageProvider.mof
  2. Net stop winmgmt
  3. Net start winmgmt
  4. Ran the co-management baseline policy from the Configuration Manager applet.


However, even after these steps, the error persisted, and the client continued to experience a provider load failure.

Before trying out the uninstall of sccm client and reinstalled, took a different approach and decided to use "ccmrepair.exe," located in the "C:\windows\ccm" folder.

After successfully running "ccmrepair.exe," attempted the WMI query again, and this time, the error message no longer appeared in the log file.

With the "CoMgmtSettingsProd" baseline policy initiated using the configuration manager applet, the WUFb workload was finally processed successfully.

But what's the connection between the WUFb workload processing and the WMI StateMessage query? Why does the client device check the StateMessage before processing the WUfB workload?

Key insight:

Before a device can process any workloads from SCCM, it first checks if "CoMgmtAllow" and "AutoEnroll" settings are already compliant. This compliance data is stored in the "StateMsg" namespace within WMI. In our case, the "StateMsg" namespace was corrupted, which prevented the workload from being processed and led to a non-compliant status in the logs.

Running the Remediation Script:

To identy the devices having similar symptoms , the following PowerShell script that can be used to identify and fix devices exhibiting the symptoms described above. It's essential to test this script before deploying it to a large number of devices.

Script Name: Remediate - StateMsg WMI Status
Description: Fix the Statemsg namespace issue for co-management WUFb workload processing.


# WMI query to Statemsg namespace
$wmiObject = Get-WmiObject -Namespace root\ccm\StateMsg -Query "SELECT * FROM CCM_StateMsg WHERE TopicType='401'"


# Check if the query was successful
if ($wmiObject) {
# Query was successful
Write-Host "StateMsg is working"
} else {
# Query failed
try {
# Run ccmrepair.exe
Start-Process -FilePath "C:\windows\ccm\ccmrepair.exe"
Write-Host "StateMsg not working, ccmrepair.exe success"
} catch {
Write-Host "StateMsg not working, ccmrepair.exe failed"

Hope you find this post useful.

Post Comment