What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When newly imaged Configuration Manager clients finish an operating-system deployment but never register, do not immediately rebuild the Management Point (MP). The client may still be in task-sequence provisioning mode, the registration request may be failing authentication or network checks, or an earlier MP removal may have stalled. In one documented incident, SiteComp.log showed a failed MP deinstallation caused by Windows error 997. After the administrator backed up and removed a stuck registry entry, MP removal completed and the role was added again. That registry change is a case-specific, last-resort workaround—not a universal ConfigMgr repair.
What is actually failing?
“The client is not visible in the console” is only a symptom. Separate these conditions before changing the MP:
- The client software is not installed or installation is damaged.
- The client is installed but remains in task-sequence provisioning mode.
- The client registered but cannot download policy.
- The client is contacting the wrong MP or cannot locate one through boundaries and site assignment.
- Registration reaches the MP but fails certificate, token, CRL, IIS, or authentication checks.
- The MP role was removed or reinstalled incompletely.
Clients need an MP for site information, assignment, policy, and normal management even when their installation files came from another source. See Microsoft’s MP role guidance.
When should an OSD client register?
During an operating-system deployment, the ConfigMgr client can remain in provisioning mode. Policy processing is intentionally suppressed so assignments for an existing computer do not run in the middle of the deployment. A successful task sequence therefore does not prove that registration has finished.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →#1 Best Overall
Evaluate registration after the task sequence exits provisioning mode. A short delay is normal; repeated retries long after completion are not. Start with ClientIDManagerStartup.log and correlate its timestamps with the task-sequence evidence in smsts.log. The incident described by HTMD Blog involved clients that remained unable to register after deployment, while existing MP activity appeared normal.
Collect the right evidence
Client logs
| Log | Use |
|---|---|
ClientIDManagerStartup.log |
Client identity creation, registration requests, confirmation, and approval state. |
ccmsetup.log |
Client installation, repair, or removal. |
client.msi.log |
Windows Installer-level failures. |
smsts.log |
Task-sequence completion and provisioning-mode context. |
LocationServices.log |
MP discovery, site location, and boundary behavior. |
PolicyAgent.log / PolicyEvaluator.log |
Whether policy retrieval starts after registration. |
Management Point logs
| Log | Use |
|---|---|
MP_CliReg.log |
Registration requests processed by the MP. |
MP_RegistrationManager.log |
Registration validation, certificates, CRL, tokens, and processing results. |
mpcontrol.log |
MP registration and availability checks. |
MP_Framework.log |
Core MP activity, including database connectivity. |
MP_GetPolicy.log |
Policy requests from clients. |
CcmIsapi.log / ClientAuth.log |
Client messaging and authentication/signing activity. |
MPSetup.log / mpMSI.log |
Role setup, MSI installation, rollback, and reinstall failures. |
Microsoft’s log reference lists these purposes. MP logs are commonly under C:SMS_CCMLogs; client logs are under %WINDIR%CCMLogs and %WINDIR%CCMSetupLogs. Site-server logs are under the Configuration Manager installation path.
Site-server logs
SiteComp.logrecords site-system role actions, failures, and retry cycles.Hman.logrecords hierarchy and site-control changes.- Setup and downloader logs matter only when the particular role installation or update invokes them.
What successful registration looks like
In ClientIDManagerStartup.log, look for a confirmation equivalent to:
[RegTask] - Client is registered. Server assigned ClientID is GUID:<client-guid>. Approval status 1
Approval values vary by authentication scenario. Microsoft documents approval status 3 in an Entra ID-based example, so do not require one value in every environment; see the registration workflow documentation.
Recommended Free Tools
Use the client GUID and timestamp to find the corresponding request in MP_CliReg.log and MP_RegistrationManager.log. A message such as “did not find client public key” can be expected before a client has registered; interpret it with the surrounding authentication and retry messages.
A practical diagnosis sequence
1. Establish the scope
Determine whether one computer, every newly imaged computer, or existing clients are affected. Record whether the problem began after MP removal, reinstall, a site upgrade, certificate renewal, or IIS/WSUS maintenance. New-client-only failures after an MP change point toward registration processing, but they do not prove the MP is the sole cause.
2. Prove the task sequence has finished its part
Review smsts.log and ClientIDManagerStartup.log after sign-in or restart. Confirm provisioning mode has ended and that registration attempts continue. Do not remove an MP solely because a client was invisible immediately after OSD.
3. Verify MP location and transport
- Confirm the site code and discovered MP in
LocationServices.log. - Resolve the MP FQDN and test the configured HTTP or HTTPS port.
- Check firewall rules, IIS response, boundary groups, and site assignment.
- For HTTPS, verify the client certificate, EKU, trust chain, SAN, CRL access, and IIS binding.
Use these checks with the actual MP name and communication mode:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsRank #3
Resolve-DnsName mp01.contoso.com Test-NetConnection mp01.contoso.com -Port 80 Test-NetConnection mp01.contoso.com -Port 443
A successful TCP connection does not prove that the MP application, authentication, or database path is healthy.
4. Correlate client and MP timestamps
- No MP entry: the request may not reach the expected MP, or the client may be using another one.
- Authentication failure: investigate certificates, CRL, tokens, and HTTPS configuration.
- MP processes the request but the client never confirms: inspect the response path, IIS, and client retries.
- Existing clients work while new registrations fail: focus on registration-specific processing and recent role changes.
5. Validate the MP installation
Read MPSetup.log, mpMSI.log, mpcontrol.log, and MP_Framework.log. The last of these is important when the web layer responds but the MP cannot connect to or authenticate against the site database. Microsoft’s deployment example explains this validation approach at Example management point deployment.
6. Check whether deinstallation is stuck
In the reported incident, SiteComp.log repeatedly showed a failure similar to:
Cannot delete registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSSMS_EXECUTIVEThreadsSMS_COMPONENT_MONITOR The operating system reported error 997: Overlapped I/O operation is in progress. Deinstallation failed and will be retried in the next polling cycle.
Error 997 confirms the reported operation encountered an overlapped-I/O condition; it does not identify which process held the registry or service state. Check for active role work, a pending reboot, endpoint-security interference, stale service activity, or broader site-component failures.
Rank #4
Safe recovery for a failed MP deinstallation
Preferred administrative path
- Record the MP server, site code, role configuration, communication mode, certificates, and current log timestamps.
- Confirm that no site upgrade, role installation, or removal operation is active.
- Verify the remote-server installation account and local administrative permissions. Microsoft discusses these requirements in site setup guidance.
- Check appropriate Configuration Manager and Windows service state during an approved maintenance window. Do not use a universal stop-service list; the correct set depends on your release and other roles on the server.
- Allow Site Component Manager to retry, then confirm successful removal in
SiteComp.log. - Re-add the MP role from the Configuration Manager console.
- Validate
MPSetup.log,mpMSI.log,mpcontrol.log, andMP_Framework.log. - Test with one controlled client before releasing a larger deployment.
Case-specific registry workaround
Only when SiteComp.log repeatedly reports failure to delete the exact key below, and the maintenance change is approved, can you consider the workaround reported by HTMD Blog:
HKLMSOFTWAREMicrosoftSMSSMS_EXECUTIVEThreadsSMS_COMPONENT_MONITOR
- Create a backup directory and export the key from an elevated command prompt:
mkdir C:Temp reg export "HKLMSOFTWAREMicrosoftSMSSMS_EXECUTIVEThreadsSMS_COMPONENT_MONITOR" "C:TempSMS_COMPONENT_MONITOR.reg" /y
The destination directory must exist and the account must have sufficient permissions. You can inspect the key with:
Get-Item 'HKLM:SOFTWAREMicrosoftSMSSMS_EXECUTIVEThreadsSMS_COMPONENT_MONITOR'
- Confirm the MP removal is genuinely stuck, no active operation is using the component, and the backup is readable.
- Remove only that problematic entry.
- Wait for or trigger the next Site Component Manager retry.
- Do not proceed until
SiteComp.logconfirms MP deinstallation completed. - Reinstall the MP role and validate its setup and health logs.
- Retest registration with a newly deployed client.
This procedure is an observed, potentially disruptive remediation for one failed-removal pattern. Microsoft’s published guidance supports the diagnostic and role-validation steps, but does not establish deletion of this key as a universal supported fix. Stop if the key cannot be exported, the role continues to change state, or another installation is active.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Test a repaired MP and client
For a controlled manual installation, Microsoft documents:
Best Value
ccmsetup.exe SMSSITECODE=P01 SMSMP=mp01.contoso.com
SMSMP specifies the MP in this installation scenario. It is different from /mp, which helps ccmsetup.exe find initial installation content and does not permanently assign the installed client to that MP; see client installation parameters.
After installation, verify all of the following:
- Registration confirmation and a server-assigned GUID in
ClientIDManagerStartup.log. - Matching registration activity in the two MP registration logs.
- Correct site and MP location.
- Successful policy retrieval in
PolicyAgent.logandPolicyEvaluator.log. - Expected console visibility and online state.
If the MP reinstall does not solve it
HTTPS and PKI
Check certificate expiry, EKU, subject or SAN, issuing-chain trust, CRL reachability, and IIS bindings. Registration processing explicitly validates certificates, CRLs, and tokens.
DNS, boundaries, and firewall
Confirm that the client resolves the intended MP, belongs to a boundary group with an MP, and can reach the configured port. A wrong boundary can make a healthy MP appear unavailable.
Identity and cloning
Duplicate hardware GUIDs, cloned client identity, or reused certificates require a separate identity-remediation plan. Do not delete client identity data as a generic response to an MP deinstallation failure.
Permissions and database health
For a remote site-system role, the installation account must administer the server. If MP_Framework.log reports database connectivity or authentication errors, repair that path rather than repeatedly reinstalling IIS components.
Cloud Management Gateway
Use a CMG only when internet-based management is the requirement and the tenant, identity, certificate, and cloud configuration are ready. CMG registration follows different logs and authentication paths; its guidance is documented at Configure clients for CMG.
When to reinstall, replace, or leave the MP alone
| Situation | Best next action |
|---|---|
| One client only; provisioning, certificate, DNS, or boundary evidence points to the client | Repair that client path; do not immediately reinstall the MP. |
| MP setup or MSI rollback is incomplete and the role removal completed cleanly | Reinstall the MP and validate all setup logs. |
| Existing clients work but new registrations fail after a role change | Correlate registration logs and inspect site-component state before rebuilding. |
| Server cannot be repaired within the service window | Add and validate a replacement MP, then remove the old role through normal administration. |
| Internet management is the real requirement | Design a CMG or supported internet-facing solution; do not use it as a generic MP repair. |
Multiple MPs can provide selection flexibility, but boundaries, hierarchy, and site configuration must be correct. See Microsoft’s site-system role documentation.
Quick Recap
What not to do
- Do not delete the registry entry before confirming the exact repeated
SiteComp.logfailure. - Do not treat a successful task sequence or TCP test as proof of registration or MP health.
- Do not confuse
/mpwithSMSMP. - Do not remove client identity data indiscriminately.
- Do not edit the registry without an export, change approval, and a rollback plan.
- Do not reinstall the MP while an upgrade, role operation, or retry is active.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
