SCCM Failed Client Push Installation

A while back, we started noticing some SCCM clients failing to push automatically on some machines. The majority of client push installations were being processed successfully and installed clients were behaving properly (we have several thousand SCCM clients). Examination of the ccm.log on the server revealed the following error when the agent is being pushed:

Unable to get Win32_OperatingSystem object from WMI on remote machine “<machinename>”

Win32_OperatingSystem is a WMI class and this indicated that WMI was acting up on the target PCs. Nevertheless, we attempted to install the client locally on one of the problematic PCs by copying the client installation folder and running ccmsetup.exe with SMSSITECODE=<code> option.

The installation was a success, however, the client failed to report back to the server. After checking several log files on the client, the following errors showed up in ClientIDManagerStartup.log:

SCCM Client Log ClientIDManagerStartup Errors

All these were calls failing further indicating that WMI was corrupt.  To confirm, we ran wbemtest.exe on the target machine, connected to root\cimv2 and ran the following query:

select * from Win32_OperatingSystem

The query failed with Invalid Class error.

Corrupt WMI repositories can be fixed or rebuilt in several ways, some of which involve renaming the repository folder and rebuilding it from scratch. This method is very invasive and will most often lead to issues. A faster way to attempt remediation is to recompile WMI MOFs using mofcomp. A simple batch file consisting of the below will accomplish this:

cd “%systemroot%\system32\wbem”

for /f %s in (‘dir /b *.mof *.mfl’) do mofcomp %s

To note that this needs to be ran as a batch file and not directly from the command line, otherwise it will most probably fail. Running this batch file from an elevated command prompt repaired WMI and the query for Win32_OperatingSystem succeeded:

WIMQ Wbmetest Win32_OperatingSystem Success

Reexamining the ClientIDManagerStartup.log showed that the client is now functioning properly and has registered with the server:

SCCM Client Log ClientIDManagerStartup Success

We used PSExec to run the script remotely on the remaining problematic machines and the issue cleared up.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.