Introduction
ManagementStudio draws a wealth of information from Microsoft System Centre Configuration Manager (SCCM) about application and hardware utilisation to help determine user and application readiness throughout a migration. Very often, organisations only realise that there's a problem with some of the SCCM agents when data about specific devices or applications don't appear as expected in ManagementStudio.
To help identify the workstations may have a non-functional SCCM agent, ManagementStudio contains datamining capability to analyse the health of the components required for data. This can be used to quickly create a list of devices that haven't reported back recently and need further investigation.
Earlier versions of Windows require a specific driver to enable the SCCM agent to benefit from software metering. However, a Microsoft hotfix can break this functionality without administrators realising as the rest of the client still functions as expected. This document details the workaround to reinstate software metering.
Applies to:
- Microsoft Windows 7 SP1
- Microsoft Windows Server 2008 R2 SP1
Symptoms
Machines that are affected by this problem often show no signs of there being an issue until SCCM clients are required to provide software metering information. Closer inspection of the SCCM client log file for software metering, mtrmgr.log, will display the following error:
CSWMtrClientConfig::Load - Failed to get an instance of CCM_SoftwareMeteringClientConfig, error 80041002
Failed to load software metering client config
StartPrepDriver - OpenService Failed with error 80070424
Failed to create instance of CLSID_ProcessEventProvider, error 80040154
Failed to create instance of CLSID_SWMtrManager, error 80040154
Without the driver loading, clients are unable to successfully collect hardware and software inventory information.
Cause
The issue is caused by a Microsoft Windows convenience rollup, KB3125574, for Windows 7 SP1 and Windows Server 2008 R2 SP1. The problem occurs if the patch is installed to the operating system (OS) before the SCCM client. This is a common scenario for any organisation that creates their “gold image” WIM file and subsequently patches it using the SCCM offline patching feature.
The workaround is to deploy a script using an SCCM Compliance Rule to detect affected machines and install the driver manually.
Identify Affected Machines
The easiest way to detect a problem machine from the SCCM console is to find machines that haven’t successfully completed a Software Scan:
The SCCM client software metering log file, mtrmgr.log, should be reviewed for each machine that has failed to complete a software scan. If the log file displays an output similar to the example in 'Symptoms', above, the likely cause is KB3125574.
Remediation
Step 1
An SCCM Configuration Baseline, containing one Configuration Item consisting of two scripts, can be used to detect and remediate this issue.
The first script evaluates whether the machine is compliant or not by using PowerShell to determine the presence of a specific registry key:
The PowerShell script will return a value of 'True' if the registry key exists or 'False' otherwise.
Step 2
If the first script determines that the client is non-compliant, a second script - containing the remediation - will run:
The script installs the Prep Driver from the local CCM folder on the client before pausing for 10 seconds to allow the driver install to complete before the CCMExec service is restarted. Once the SCCM client has re-initialised, a hardware and software scan is triggered.
Step 3
Both scripts are linked together using a Compliancy Rule in SCCM. The rule is looking for an output of 'True' from the first script and will only run the second script should a 'False' be returned:
Step 4
The Configuration item should be limited to run only against Windows 7 SP1 and Windows Server 2008 R2 SP1 clients as these are the only operating systems affected:
Once the compliance settings are complete, the Configuration Baseline can be deployed to a device collection containing Windows 7 and Server 2008 machines.
Verify the Fix
Once the Compliance Baseline has been deployed to the machine(s) it will appear in the 'Configurations' tab of the SCCM client properties. It will run on the schedule set within the deployment. Once run the 'Compliance State' should change from 'Unknown' to either 'Compliant' or 'Non-Compliant':
The baseline will re-evaluate after the remediation script has run to determine whether the Prep Driver has been successfully installed:
To ensure the fix has been correctly applied, there are two further checks that should be performed on one of the machines affected by the issue:
- Check the registry for the presence of the 'prepdrvr' registry key:
- The “mtrmgr.log” should now look healthy and show the following messages:
Once the machine has completed its hardware and software scans, these should now be successfully passed to the clients Management Point and available in the SCCM console:
Resources
Compliance Baseline report