Configuration Manager client not receiving policy: PolicyAgent.log and CcmMessaging.log

A Configuration Manager client (the agent many admins still call the SCCM client) can look installed and healthy yet never pick up new deployments, client settings or maintenance windows. Policy depends on a chain: the client registers, finds its management point (MP), requests its assignments and downloads the policy bodies. In this post I'll follow that chain through the client logs, fix the usual breaks and show how to prove policy is flowing again.

Symptoms#

• New deployments never appear in Software Center, and changed client settings don't apply.
• The Actions tab of the Configuration Manager control panel lists only Machine Policy Retrieval & Evaluation Cycle and User Policy Retrieval & Evaluation Cycle.
• In the console, the device's last policy request is old or empty, or the client shows as inactive.
• Logs in C:\Windows\CCM\Logs contain lines like these:

PolicyAgent.log             Client is not registered yet. Ignore the policy assignments request.
ClientIDManagerStartup.log  RegTask: Failed to send registration request message. Error: 0x87d00231
ClientIDManagerStartup.log  [RegTask] - Server rejected registration request: 3
CcmMessaging.log            Failed in WinHttpSendRequest API, ErrorCode = 0x2ee7

Why it happens#

On the client policy polling interval (60 minutes by default, set in client settings), the policy agent asks the MP for machine policy assignments, downloads new or changed policies and passes them to the policy evaluator, which applies them locally. User policy takes the same path when it's enabled. Each step writes to its own log:

The chain usually breaks in one of four places:

• Not registered: the MP never accepted the client, so the policy agent ignores the request (the first log line above).
• MP unreachable: DNS, firewall, proxy or certificate trouble. 0x2ee7 is WinHTTP error 12007: the server name couldn't be resolved.
• Cloned identity: devices imaged from a reference computer that still held its SMSCFG.INI and SMS certificates share one GUID, so the site sees one client where there are many.
• Wrong site or MP: no boundary group for site assignment, or the client is talking to an MP it shouldn't.

How to fix it#

1. Confirm registration#

Open ClientIDManagerStartup.log. A registered client logs a line like [RegTask] - Client is registered. Server assigned ClientID is GUID:... Approval status 1. If it keeps sending registration requests or the server rejects them, read MP_RegistrationManager.log on the MP for the reason, and check in the console that the device record isn't blocked or waiting for approval.

2. Prove the client can reach its MP#

Get-CimInstance -Namespace root\ccm -ClassName SMS_Authority | Select-Object Name, CurrentManagingPoint
Resolve-DnsName mp01.contoso.com
Test-NetConnection mp01.contoso.com -Port 80
Invoke-WebRequest 'http://mp01.contoso.com/sms_mp/.sms_aut?mplist' -UseBasicParsing | Select-Object StatusCode

Name should show your site code (for example SMS:PS1) and a StatusCode of 200 means the MP answered. For an HTTPS-only MP, test port 443 with https:// and make sure the device has a valid client authentication certificate. If several clients fail the same test, the MP is the problem: see troubleshooting an unhealthy management point. On laptops using mobile networks, also check the client setting for communication on metered connections.

3. Give cloned devices their own GUID#

Compare the client ID on two suspect devices:

Get-CimInstance -Namespace root\ccm -ClassName CCM_Client | Select-Object ClientId

If the IDs match, reset the identity on each clone. The clean-up mirrors Microsoft's preparation steps for imaging: stop the SMS Agent Host, delete SMSCFG.INI from the Windows folder and remove the certificates from the local computer's SMS store:

Stop-Service CcmExec
Remove-Item "$env:WINDIR\SMSCFG.INI" -Force
Get-ChildItem Cert:\LocalMachine\SMS | Remove-Item
Start-Service CcmExec

ClientIDManagerStartup.log should then show a registration request with a new GUID; if the ID doesn't change, reinstall the client. If your hierarchy settings require conflicting records to be resolved manually, resolve the new record under Monitoring › System Status › Conflicting Records.

Fix the image as well. Before capture, stop CcmExec, delete SMSCFG.INI, remove the SMS store certificates and any other client authentication certificates, and don't put a site code on the reference computer's ccmsetup command line. A capture task sequence's Prepare ConfigMgr Client for Capture step removes the client for you.

4. Check site assignment and boundaries#

ClientLocation.log records the assigned site and LocationServices.log the MPs the client found. If assignment fails, or the client lists MPs from the wrong site, add the device's subnet, IP range or AD site to a boundary group used for site assignment, as explained in boundaries and boundary groups explained. Then refresh locations with schedule ID {00000000-0000-0000-0000-000000000024} (see step 5 for the syntax).

5. Request policy and read the result#

Trigger retrieval from the control panel (Actions › Machine Policy Retrieval & Evaluation Cycle › Run Now), from the console (right-click the device, Client Notification › Download Computer Policy), or in PowerShell with the schedule IDs documented for the TriggerSchedule method:

# Machine Policy Assignments Request, then Machine Policy Evaluation
Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{sScheduleID='{00000000-0000-0000-0000-000000000021}'}
Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{sScheduleID='{00000000-0000-0000-0000-000000000022}'}

Use ...026 and ...027 for the user policy equivalents. Then follow the request through CcmMessaging.log (no failed posts), PolicyAgent.log (assignments requested and policies downloaded) and PolicyEvaluator.log (policies applied).

Verify the fix#

1. ClientIDManagerStartup.log shows the client registered with Approval status 1, and its GUID is unique.
2. PolicyAgent.log no longer reports that the client isn't registered, and CcmMessaging.log shows no new errors.
3. The control panel's Actions tab lists the full set of cycles, such as hardware inventory and software updates scan.
4. The console shows a recent policy request for the device, and a test deployment appears in Software Center.

Prevent it next time#

• Build the imaging preparation steps into every capture process, and never capture a registered client without them.
• Add new subnets and VPN ranges to boundary groups as part of the network change, not after.
• Watch MP health and client activity; inactive and unhealthy clients covers the cleanup side.
• If the client never installed cleanly, start with the client installation error codes quick reference.

References#

• TriggerSchedule method in class SMS_Client
• How to deploy clients to Windows computers in Configuration Manager
• Log file reference for Configuration Manager