Support Tip: ConfigMgr clients fail to register and generate 0x80040231 errors in CCMExec.log

Support Tip: ConfigMgr clients fail to register and generate 0x80040231 errors in CCMExec.log

  • Comments 4
  • Likes

imageHi everyone, Arvind Kr. Rana here with another Configuration Manager support tip for you. I’ve run across this a couple times and thought it would be worth mentioning here in case you happen to run into the same issue.

What happens is that we try to install the Configuration Manager client using following command line where “SIGNCERT.cer” is the document signing certificate:

ccmsetup.exe /native:Fallback SMSSIGNCERT="c:\SIGNCERT.cer" SMSSLP=serverName.domain.com SMSSITECODE=<siteCode>

The client was getting installed, however there were failures with the registration process with the Management Point. Looking in CCMExec.log we found the following:

CCMHTTP] HTTP ERROR: URL=http://<Site Server Name>/ccm_system/request, Port=80, Protocol=http, SSLOptions=0, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE CCMEXEC
Raising event:
instance of CCM_CcmHttp_Status
{
DateTime = "20121212220939.655000+000";
HostName = "<Site Server Name>";
HRESULT = "0x8004027e";
ProcessID = 4000;
StatusCode = 403;
ThreadID = 3024;
};
Successfully sent security settings refresh message.
HandleRemoteSyncSend failed (0x80040231).
CForwarder_Sync::Send failed (0x80040231).
CForwarder_Base::Send failed (0x80040231).

What we did to resolve the issue was create a new client certificate on the Certificate Authority (CA) and exported it along with the private key, then imported it on the client machine and placed it in the personal store. Once we did this the client installed successfully, but we now found that it was rejecting the policy download with following errors:

Raising event:
instance of CCM_CcmHttp_Status
{
ClientID = "GUID:A6CFDA97-D7FF-4620-B889-625C09CA8C17";
DateTime = "20121218161801.931000+000";
HostName = "<Site Server Name>";
HRESULT = "0x00000000";
ProcessID = 2636;
StatusCode = 0;
ThreadID = 3004;
};
The certificate chain processed correctly but terminated in a root certificate not trusted per ConfigMgr CTL
Rejected the new site signing certificate... 
Name      : The site code of this site server is <Site Code>
Sha1 Hash : 6FA85535F1D57B118451EB211776187BE53747F2
Valid From: 2012-05-31, 16:05 
Valid To  : 2014-05-31, 16:15 
Raising event:
instance of CCM_LocationServices_SiteSigning_AuthFailure_Trust
{
ClientID = "GUID:A6CFDA97-D7FF-4620-B889-625C09CA8C17";
DateTime = "20121218161801.947000+000";
HRESULT = "0x800b0109";
ProcessID = 2636;
ThreadID = 3004;
};
Failed to set site signing certificate (0x800b0109).
Failed to update Signing Certificate over HTTP with error 0x800b0109.

We did some more investigating and found that the document signing certificate specified in the command line was issued from a decommissioned CA. We exported the working certificate from the site server, imported it on the client machine and corrected the command line. After doing so, we ran the command again and the client installed and registered as expected.

The takeaway here is that while there can be multiple causes that may prevent the client install registration process, we need to make sure that we have a valid client authentication certificate and document signing certificate present on the target machine in order to successfully install the client.

Special thanks to Prabhat Joshi and Ashish Kumar for their work on troubleshooting this issue.

Arvind Kumar Rana | Senior Engineer | System Center Team

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi,

    0x80040231 is a very generic error which can be seen in Clientidmanagerstartup.log and ccmexec.log. Before starting with troubleshooting this error make sure we enable DebugLogging and Verbose logging on client machines by following this blog blogs.iis.net/.../enable-debuglogging-and-verbose-logging-on-sccm-clients.aspx.

    This will provide additional information and right direction in troubleshooting this error.

  • I am having the same issue with a server 2012 client, but in our case, a third-party certificate in the "Personal" store of the local computer had been created by an install/configure of Symantec Backup Exec 2012. It is a self-signed cert, with what looks like a self-signed root. (Not a known root, but one specific to that server.)

    Trying to resolve this, I found the two certificates in the SMS "folder" (Logical Store Name) of the Local Computer account's certificate stores. (Used mmc.exe -> Certificates -> Local Computer) I right-clicked and copied the two certs in the "SMS" folder/store that are labeled as 'issued to' and 'issued by' "SMS"; then I pasted them into the "Personal" folder/store. I did not remove the third-party certificate, yet.

    I uninstalled sccm, then re-installed after a reboot. Still was getting the error regarding an invalid certificate.

    I exported the third-party cert, with private key and all extended properties, to back it up. Then I deleted it. VIOLA! The client successfully registered, and data started populating.

    After waiting about 40 minutes, making sure everything was going well, I imported the third-party certificate back in - since BE2012 is probably not going to work properly without it. ARGH! The errors about a failure in client certificate immediately started in the SMS_MP_CONTROL_MANAGER site component status message viewer. I deleted it back out again, and it stopped creating those errors.

    So the big question right now is - HOW DO I TELL THE SCCM CLIENT TO USE ONE OF THE 'SMS' Certifcates instead of A THIRD-PARTY CERTIFICATE? WHY IS IT EVEN DOING THAT IN THE FIRST PLACE? Or is it presenting all certificates in that store, and failing when any one of them cannot be resolved to a known root?

    The only work-around I can think of trying is to import the self-signed root found into the trusted store of the management point. Which I am not going to do, not at this point. This may snowball into having to do this for a bunch of clients.

    Does anyone have any additional information on this?

    Thanks!

  • Hi,

    Usage of wildcard cert is the reason why you are facing issues with registration of SCCM client.

    If at all you would like to go for it, please buy every cert by machine name , configure them with their intended purpose as mentioned on technet and place them on their respective locations and then it should work.

    Reason why it worked for sometime in your case ,is becuase after you deleted wildcard cert, client automatically picked cert issued by internal CA and got itself registered.

  • Having exactly the trouble noted by twgage but haven't found any solution that works. In our case McAfee has a cert in the Personal store that keeps getting selected by SCCM and the client fails to register.