More and more SCCM environments are using Certificate Client-Server authentication. And of course, you also want to use this to get your environment more secure.
In the past ánd recently I ran up to a problem with deploying an application to some Windows servers. I tried to push a certain application to a specific server using a collection with direct servernames specified. At that moment I found out that the server wasn’t there to select! So after some investigation I found out that this server had a duplicate SCCM GUID. In this blog I have simulated the situation at home and will try to explain what happens.
These are the servers listed in my SCCM console. 1 server(wijten01) is missing in this list.
Here’s where the ‘must have’ collection ‘Duplicate GUIDS’ comes in.
A lot of articles can be found on the internet to find clients with duplicate GUIDS. I used this query to create a collection for this:
select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.ResourceId in (select SMS_GH_System_System.ResourceID from SMS_G_System_System join SMS_GH_System_System on SMS_G_System_System.ResourceID = SMS_GH_System_System.ResourceID where SMS_G_System_System.Name <> SMS_GH_System_System.Name)
This way I found the server (Wijten04) with a duplicate GUID. When looking at the Hardware History inventory I saw that one server with the same GUID toggled its server name between the 2 servers.
So, my investigation went further on the client servers themselves. Why are they using the same GUID?
(What is important to know is that, when using PKI, by default the SCCM agent generates a Client GUID based on a certificate in the personal Computer store.)
On both servers I saw in the ClientIDManagerStartup.log this line:
On server ‘Wijten01’:
And on server ‘Wijten04’:
So, they both use the same certificate!
Now let’s have a look at the certificates on those clients. For this I always use certlm.msc from the run box for this (Tip of the day!)
On wijten04 there was a stranger there. A Certificate (probably used for a webserver) has the name of the other server (wijten01.workgroup.nl)
So now we know what’s happening. But why?
For this we have to go to the SCCM console and have a look at some site settings. Most likely you have the same settings as I have.
As you can see, the SCCM agent will pick the certificate which lasts longest. In my case the server ‘Wijten01.workgroup.nl’ has the latest expiry date. So, the SCCM agent will use this certificate to generate a GUID.
At one customer I also saw that if the expiration date of the certificates is the same, then it will pick the certificate with the lowest alphabetical subject name.
So now we know why they have the same GUID.
Luckily, I found a solution for this.
One solution is to delete the unwanted certificate. If possible, this would be the best and easiest solution.
But what If you don’t want to delete this. This might be a website certificate, or this may be used by some vague application you don’t have knowledge of.
In that case you can move your certificate to the ‘Web Hosting’ folder. This should have no consequences for any website or application. However, there might be a short hiccup when you have moved the certificate.
Instantly after moving the certificate, the SCCM agent will start searching for a new certificate in the Personal computer certificate store, resulting in a new GUID for this server.
A better solution would be the possibility to use variables when selecting a certificate as defined with the site settings mentioned above. So please vote for this on the Configuration Manager Uservoice page.