SCCM/ConfigMgr, Technology, Windows

ConfigMgr client registration rejected

I recently ran into an issue I hadn’t seen before, and ended up having to engage Microsoft support to get it resolved, so thought I would share what I learned.  There were two Server 2008 R2 SQL servers that were a member of a cluster that were not checking in, and apparently hadn’t been for quite some time before it was brought to my attention.  Looking the devices up in the console they both showed “No” under the client column.  

Looking at the logs on the devices, they had not updated in quite some time… it was as if the client was installed and everything was normal, but nothing was happening.  None of the log files had been written to in months.  I proceeded to uninstall/reinstall the client.  After the reinstall completed there was a very limited set of logs in the C:\Windows\CCM\Logs directory, and even though ccmsetup.log showed Exit 0, install succeeded, things still weren’t right.  At this point, I started digging a little deeper.

This is when I found messages in the ClientIDStartupManager.log file saying registration for GUID had been rejected by the server.

Next I went looking on the Site Server in Program Files\SMS_CCM\Logs\ at MP_Registration.log and found:

The GUID seen here matched the GUID I saw previously in the ClientIDStartupManager.log file on the client.

The first thing I did was go find the two devices in the database and right click them, expecting to be able to click “Unblock”, but no such luck.  Approve, Block and Unblock were all unavailable.

Next I unleashed the Google Fu, found a few references to other folks having a similar issue that related this SQL query:

When I ran that on my ConfigMgr database, it did indeed come up with the two device GUIDs that I was having issues with.  I took this info to my DBA expecting to be able to just either set IsRevoked=0 or delete the rows altogether.  He took a look and determined there were too many triggers associated with that data and he wasn’t comfortable modifying it.

At this point I started thinking… couldn’t I just force the clients to generate new GUIDs and be on my merry way?  Turns out, you can do that.  I don’t truly think all of these steps are necessary, but just for good measure I did the following:

  1. Uninstall the ConfigMgr client via ccmsetup.exe /uninstall
  2. Completely remove C:\windows\ccm, C:\windows\ccmsetup, and C:\windows\ccmcache directories
  3. Remove C:\windows\SMSCFG.ini
  4. Delete the two SMS certificates from the computer certificate store by removing the entries under HKLM:\SOFTWARE\Microsoft\SystemCertificates\SMS\Certificates in the registry.
  5. Delete both objects from the SCCM console.

I then reinstalled the client with the following command line:

I found the reset key information option here.  I don’t know that it really applied in this situation, but it was one of those “and take that for good measure” type of things.  When the client installs finished, the two servers did in fact have new GUIDs.  However, I was still seeing the registration rejected messages.

When I ran that same SQL query from above, there was nothing coming up for the two new GUIDs.  So I took it one step farther and just looked for the new GUIDs in general with:

This still came up with nothing, so it was as if these new GUIDs did not exist in the database.  At this point I threw in the towel and opened up a case with Microsoft.

After reviewing the logs, these were the steps that I got back from them that ultimately resolved the issue, it was a total of four SQL deletes that removed the stale info.  This also validated that I was mostly on the right track to begin with.

Their advice was to uninstall the client from both servers, delete both objects in the console, and then run the following on the database:

Afterwards I reinstalled the client, and both servers immediately registered and pulled policy as normal.  Somebody that knows more about it than me will likely tell me I’m wrong here, but I assume that the system_disc references AD system discovery information.  So I would assume that the system discovery for the server name was basically tied to the GUID in the ClientKeyData table so that even though I generated new GUIDs, there was still a reference to the old ones.  Therefore, no matter what I did they were always going to come back rejected until that stale info was cleared from the database.

As to how these two servers ended up in this revoked state to begin with?  Not a clue.  They’ve been around for quite awhile, and I’m pretty sure were migrated from a ConfigMgr 2007 site before my time.  I would guess that at some point somebody accidentally blocked them, and it all went downhill from there.

 

1 Comment

  1. Sys Admin

    I had this issue on multiple machines and the steps you mentioned above works like a charm! Thank you for taking time to put this together.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.