Management point unhealthy: mpcontrol.log, IIS checks and clients that can't find an MP

The management point (MP) is the front door of a Configuration Manager site: clients register, fetch policy and find content through it. When it breaks, everything downstream looks broken too: clients go inactive, deployments sit in Unknown and new clients never register. In this post I'll show how to prove whether the MP itself is healthy, read mpcontrol.log, fix the usual IIS, SQL and certificate causes, and then check the client side.

Symptoms#

• In Monitoring › System Status › Component Status, SMS_MP_CONTROL_MANAGER is in a warning or critical state with status message 5436: MP Control Manager detected management point is not responding to HTTP requests, followed by the HTTP status, often 500.
• Monitoring › System Status › Site Status shows the management point role with errors.
• Clients log failed requests in CcmMessaging.log, keep retrying registration, or show only two actions in the control panel applet.
• The MP's mplist test URL returns an error instead of XML.

Why it happens#

An MP is a set of ISAPI extensions in IIS (the SMS_MP and CCM_* virtual directories, in application pools such as SMS Management Point Pool) plus components hosted by the SMS Agent Host (CcmExec) service on the MP server. To answer clients it queries the site database, connecting as its computer account (or the MP database connection account) through the smsdbrole_MP database role. Every 10 minutes the SMS_MP_CONTROL_MANAGER component sends a test request to the MP and writes the result to mpcontrol.log; a failure raises 5436. The usual causes:

• IIS: website or application pool stopped, bindings changed, or a required IIS or BITS feature removed.
• SQL: the MP lost its smsdbrole_MP membership, SQL Server SPNs are wrong, or the database moved.
• Certificates (HTTPS): an expired or unbound server certificate in IIS, an untrusted chain, or no client authentication certificate on the MP for the self-test.
• Network: the MP is healthy but clients can't reach it (DNS, firewall, proxy).

How to fix it#

1. Read mpcontrol.log#

mpcontrol.log is in the Configuration Manager Logs folder on the server hosting the MP (<install path>\Logs on a site server). A healthy check looks like this:

Call to HttpSendRequestSync succeeded for port 80 with status code 200, text: OK
Http test request succeeded.
Successfully performed Management Point availability check against local computer.

A failing one:

Call to HttpSendRequestSync failed for port 80 with status code 500, text: Internal Server Error
Http test request failed, status code is 500, 'Internal Server Error'.

Ignore the availability-check line; it appears even when the HTTP test fails. The result points you in a direction:

2. Test the MP yourself#

$mp = 'cm01.contoso.com'
Invoke-WebRequest "http://$mp/sms_mp/.sms_aut?mplist" -UseBasicParsing | Select-Object StatusCode, Content
Invoke-WebRequest "http://$mp/sms_mp/.sms_aut?mpcert" -UseBasicParsing | Select-Object StatusCode

Good looks like status 200, with mplist returning an XML list of the site's MPs and mpcert returning XML with the MP's certificates. Run it on the MP, then from a client subnet: if it works locally but not remotely, the MP is fine and the problem is DNS, firewall or proxy. For an HTTPS-only MP, use https:// from a machine with a client authentication certificate.

3. Check IIS and the services#

Import-Module WebAdministration
Get-Website | Select-Object Name, State
Get-ChildItem IIS:\AppPools | Where-Object Name -match 'SMS|CCM' | Select-Object Name, State
Get-Service W3SVC, CcmExec | Select-Object Name, Status
Get-WindowsFeature Web-ISAPI-Ext, Web-Windows-Auth, Web-Metabase, BITS-IIS-Ext | Select-Object Name, InstallState

Everything should be Started, Running and Installed; those features are among the MP prerequisites. Then open the IIS log (by default under C:\inetpub\logs\LogFiles) and find requests to /sms_mp/.sms_aut and /ccm_system/request. The status and substatus columns show whether IIS rejected the request (401 or 403) or the MP failed it (500).

4. Check SQL access#

Status message 5436 lists SQL as its first possible cause. The MP's own logs are in SMS_CCM\Logs on the MP (or %windir%\CCM\Logs if the client was installed on that server before the role). Look for lines starting with MPDB ERROR in files such as MP_GetAuth.log and MP_Location.log. Then confirm that the MP's computer account (CONTOSO\CM01$), or your MP database connection account, is a member of smsdbrole_MP in the site database:

SELECT m.name AS member
FROM sys.database_role_members AS rm
JOIN sys.database_principals AS r ON rm.role_principal_id = r.principal_id
JOIN sys.database_principals AS m ON rm.member_principal_id = m.principal_id
WHERE r.name = 'smsdbrole_MP';

After moving the database or changing the SQL Server service account, also check the SQL Server SPNs.

5. Reinstall the role if the plumbing is damaged#

If virtual directories are missing or IIS is beyond repair, remove the management point role in Administration › Site Configuration › Servers and Site System Roles, confirm the removal in MPSetup.log and mpMSI.log (next to mpcontrol.log), restart the server and add the role back. sitecomp.log on the site server tracks the installation, and mpMSI.log should end with Installation success or error status: 0. If it's your only MP, plan for clients being without one in the meantime.

6. Check the client side#

Once the MP answers, confirm clients use it. In C:\Windows\CCM\Logs:

• LocationServices.log shows the assigned MP, the current AD site and the MPs the client found.
• CcmMessaging.log records every request. A line like Post to http://cm01.contoso.com/ccm_system/request failed with 0x87d00231 is generic; the lines before it carry the real cause, such as 0x80072EE7 (name not resolved), 0x80072EFD (can't connect) or an HTTP 403 or 500 from the MP.
• ClientIDManagerStartup.log records registration; a client that can't register keeps retrying here.

Get-CimInstance -Namespace root\ccm -ClassName SMS_Authority | Select-Object Name, CurrentManagingPoint shows which MP the client is using right now.

Verify the fix#

1. The next check in mpcontrol.log logs Http test request succeeded., and SMS_MP_CONTROL_MANAGER stops raising 5436.
2. mplist and mpcert return 200 from a client subnet.
3. On a client, run Machine Policy Retrieval & Evaluation Cycle: CcmMessaging.log shows no failed posts and PolicyAgent.log shows policy arriving.
4. Affected devices show a fresh Last Policy Request time in the console.

Prevent it next time#

• Run at least two MPs in a primary site that serves many clients.
• Alert on SMS_MP_CONTROL_MANAGER errors, so you hear about 5436 before clients go inactive (see inactive and unhealthy clients).
• Track expiry of the IIS server certificate and the MP's client authentication certificate.
• Keep the MP's IIS free of unrelated web applications, and put IIS and Windows feature changes under change control.
• After any SQL migration, re-check smsdbrole_MP membership and SPNs.

References#

• Log file reference for Configuration Manager
• Windows Firewall and port settings for clients in Configuration Manager