Every Configuration Manager site collects clients that stop reporting or fail their health check, and those devices quietly miss applications, updates and inventory. The console gives you two separate signals, client activity and client check, and they point to different problems. In this post I'll explain both, show how to read CcmEval results on a device, repair the common failures without making things worse, and clean up records that will never come back.
Symptoms#
- Monitoring › Client Status shows a growing share of inactive clients or failed client checks.
- Devices show Inactive in the Client Activity column of Assets and Compliance › Devices, or a failed client check in the details pane.
- Deployments to those devices stay in Unknown and their inventory is weeks old.
- The same computer appears twice, one record marked obsolete.
Why it happens#
Configuration Manager tracks three different things, and mixing them up is the most common mistake:
| Signal | What it measures | Usual cause when bad |
|---|---|---|
| Online status | The client sends a small message to its management point (MP) over the client notification channel; nothing for five minutes means offline | Device off, asleep or off the network |
| Client activity | Site side: has the device requested policy, sent a heartbeat or sent hardware inventory within the window (seven days by default)? | Device retired or re-imaged, or it can't reach an MP |
| Client check | Device side: the result of CcmEval, the health evaluation the client runs on itself | A broken local component: service, WMI, prerequisite |
So inactive means the site hasn't heard from the device, while a failed check means the device reported something broken. An active client can fail its check, and a device that died months ago can still show its last Passed. Inactivity usually comes from retired or re-imaged devices (a re-imaged device gets a new record and the old one is marked obsolete), laptops off the corporate network without a cloud management gateway, clients stuck in provisioning mode, and MP or certificate problems.
How to fix it#
1. Separate the dead from the broken#
In Monitoring › Client Status, select Client Activity or Client Check, scope the charts to a collection and drill into a category to list devices. For a reusable list, create a collection with this query:
select SMS_R_System.ResourceID, SMS_R_System.ResourceType, SMS_R_System.Name,
SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client
from SMS_R_System
inner join SMS_G_System_CH_ClientSummary on SMS_G_System_CH_ClientSummary.ResourceId = SMS_R_System.ResourceId
where SMS_G_System_CH_ClientSummary.ClientActiveStatus = 0Then compare with Active Directory, for example Get-ADComputer PC042 -Properties LastLogonDate, Enabled. A disabled or long-silent computer account means the device is gone: clean it up (step 5). If it's alive, work through steps 2 to 4 on the device.
2. Read the client check on the device#
CcmEval runs from a scheduled task under Microsoft › Configuration Manager in Task Scheduler. It logs to C:\Windows\CCM\Logs\CcmEval.log (CcmEvalTask.log covers the scheduled runs) and writes results to C:\Windows\CCM\CcmEvalReport.xml, which you need an elevated prompt to copy. Run it on demand with C:\Windows\CCM\CcmEval.exe. The main checks:
| Check | If it fails |
|---|---|
Client installed correctly; prerequisites listed in C:\Windows\ccmsetup\ccmsetup.xml present | Reinstall the client |
| More than 1% free space on drive C: | Free up disk space |
SMS Agent Host (CcmExec) exists, is automatic and running | CcmEval fixes startup type and state; if the service is missing, reinstall |
| WMI repository integrity and the client's WMI event sink | Event sink: restart CcmExec. Repository: step 3 |
Antimalware service and Windows Update (wuauserv) startup types | Reset the startup type, then find the Group Policy or tool that keeps changing it |
Microsoft Policy Platform service (lppsvc) | Let CcmEval remediate; reinstall the client if it keeps failing |
By default CcmEval also remediates, for example by starting a stopped service; clients installed with NOTIFYONLY=TRUE only report. An old evaluation date on an active, healthy client isn't necessarily a problem, because the client doesn't always upload a new report when nothing has changed.
3. Repair WMI carefully#
winmgmt /verifyrepository
winmgmt /salvagerepositoryRun the first command. If the repository is consistent, leave WMI alone: the problem is elsewhere. If it's inconsistent, salvage it, verify again and rerun CcmEval; reinstall the client if its checks still fail. Keep winmgmt /resetrepository and old "delete the Repository folder" scripts as a last resort: they throw away registrations from every other product on the device too.
4. Reset or reinstall the client#
A client left in provisioning mode by a failed task sequence doesn't process policy and drifts towards inactive. Check and clear it:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\CCM\CcmExec' | Select-Object ProvisioningMode
Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName SetClientProvisioningMode -Arguments @{ bEnable = $false }For anything CcmEval can't repair, run C:\Windows\ccmsetup\ccmsetup.exe /uninstall, wait for ccmsetup.log to finish, and reinstall from the site's Client share (see reading ccmsetup.log). If the client is healthy but can't talk to the site, check the management point.
5. Clean up records that won't come back#
In Administration › Site Configuration › Sites, select the site and choose Site Maintenance on the ribbon. The three tasks that matter here are disabled by default in a primary site:
| Task | What it does | Default age |
|---|---|---|
| Delete Inactive Client Discovery Data | Deletes discovery data for clients marked inactive by your client status settings | 90 days |
| Delete Obsolete Client Discovery Data | Deletes records marked obsolete, usually replaced by a newer record for the same device | 7 days |
| Clear Install Flag (Clear Undiscovered Clients in the docs) | Clears the installed flag for clients with no heartbeat in the rediscovery period, so client push can reinstall them | 21 days |
Set the inactive-data age well above your heartbeat discovery schedule and the longest time a device can legitimately be away. Active Directory System Discovery recreates deleted records while the computer account exists, so clean up stale AD accounts too. The activity window itself is under Client Status Settings on the ribbon of Monitoring › Client Status.
Verify the fix#
CcmEval.logshows a completed run, and every check in the report passed.- Trigger a heartbeat (discovery data collection cycle) and a machine policy request so the site hears from the device:
PowerShell
Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000003}' } Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000021}' } - After the site next refreshes client status, the device shows Active with a passed client check, and the percentages in Monitoring › Client Status improve.
Key takeaways#
- Inactive means a communication problem or a dead record; a failed check means a local problem.
- Add alerts on important collections (collection Properties › Alerts) for low client check, activity or remediation rates.
- Enable the cleanup tasks with sensible ages, and keep Active Directory tidy.
- Don't push WMI reset scripts fleet-wide; verify, salvage, then reinstall.

