20000 Clients lost self-signed certificate after Configuration Manager upgrade to 2107. Now showing "none" in Client Certificate

this is evil evil 96 Reputation points

We have performed an upgrade of our configuration manager infrastructure to 2107. We use configuration manager to manage all of our endpoints and servers. Normally when we perform these upgrades, we only upgrade the Configuration Manager agent on our endpoints during stages, so it's not everyone that gets the newest client at the same time, but this time it immediately triggered on most of our devices, due to a mishap.

After the configuration manager client is upgraded to the latest version, it seems it's loosing it's client certificate. This issue has happened on all of our devices that has received the latest agent, and is currently causing havoc, as they clients can't access MPs, get policies or get software deployed etc. - It's also impacting the deployment of new devices.
We've tried a bit of troubleshooting in attempts to fix it but before I list it here, just wanted to know if anyone is in the same boat as us?

We've raised a case with Microsoft early in the morning today CET, but we are struggling with getting them to take any action.

P.S: We are using Enhanced HTTP and not PKI


Microsoft Configuration Manager
0 comments No comments
{count} votes

Accepted answer
  1. this is evil evil 96 Reputation points

    FYI: We worked with Microsoft over night, and we found the culprit of the issue.

    TL;DR: The site-server computer-object was missing the necessary privileges to publish site-data to ADDS.

    The error was somewhat specific to our environment, as it tied together with a server migration we performed on our ConfigMgr server some 3 months ago (2012r2 -> 2019). We installed a new server and renamed the old server to "sccmserver-old" while the new server got the old SCCM Server name "sccmserver". However, it seems a migration step that was actually in our migration plan was missed. Specifically we needed to make sure the new computer object was added to the relevant AD Groups that gave it the permissions to publish site data to ADDS.
    Apparently this also had a delayed fuse, as the impact of the error we are seeing here where no agents is able to communicate with MPS, only triggered after a routine upgrade of ConfigMgr to 2107.

    This was otherwise also correlated by the Microsoft engineer from the following logs:
    "From locationservice.log
    Retrieved lookup MP(s) from AD LocationServices 9/3/2021 1:44:35 AM 3684 (0x0E64)
    Raising event:
    instance of CCM_CcmHttp_Status
    ClientID = "<Removed>";
    DateTime = "20210902234435.700000+000";
    HostName = "<Removed>";
    HRESULT = "0x00000000";
    ProcessID = 2744;
    StatusCode = 0;
    ThreadID = 3684;
    LocationServices 9/3/2021 1:44:35 AM 3684 (0x0E64)
    Failed verify the signature for issuing root cert list blob .... </Cert></Certs></SMSIssuingCerts>' with error '0x80090006' LocationServices 9/3/2021 1:44:35 AM 3684 (0x0E64)"

    0 comments No comments

1 additional answer

Sort by: Most helpful
  1. Jason Sandys 30,936 Reputation points Microsoft Employee

    Have you reviewed clientidmanagerstartup.log?