PXE boot creates a new record for computers after reinstalling the OS using PXE

Hi,
I spent this week trying to understand this issue from a lot of SCCM folks, thanks god I finally got it, so I would like to share it with you:

When you take a laptop, PXE boots it and drops an image onto it. ConfigMgr client installs and laptop joins site and applies packages – cool! Now then you clear PXE advertisement and roll out an OS onto that system again. There has been no change at all on the laptop so all the BIOS GUIDS etc. are identical, however a new ConfigMgr resource record and a new ConfigMgr GUID is assigned to the machine. The machine maintains its domain SID, MAC address, SMBIOS GUID etc. so why SCCM is creating the a new records:

This is the default behavior If site in mixed mode, and manually resolve conflicts is not enabled, the rebuilt machine gets new sccm identity (guid). If the site setting to manually resolve conflicts is enabled, then those records would appear in the resolve conflicts node. If in native mode this should not occur.

The basic problem is that when a computer is re-imaged from bare-metal in mixed mode security, ConfigMgr has no way to know if it’s really the same computer and you want it to have the same identity, or whether it is some rogue computer trying to usurp the identity of an already managed computer. PXE is a very insecure protocol, and things like the MAC address and SMBIOS are easily spoofed.




The “Manually resolving conflicting records” option is a site-wide setting, but if you set it, it requires IT Admin intervention to resolve the conflict. The current behavior is not considered to be a bug, though arguably we should offer an “automatically merge” option that doesn’t require IT Admin intervention

In native mode you don’t have this issue because of the certificates, In native mode, essentially SCCM punted the problem off to whomever (or whatever) is issuing the certificates. If the certificate issuer thinks it’s the same computer, then the new issued certificate should have the same subject name and #2 under Native Mode Security in the slide below applies. If the certificate issuer doesn’t think it’s the same computer or doesn’t know, then the new issued certificate should have a different subject name and #3 under Native Mode Security applies.

But How the certificate issuer knows that the computer is old is new one then?

Could be by a wide spectrum of different ways, depending on how certain the certificate issuer wants to be that it really is the same computer and not some rogue.

At the least secure, but most automatic, end of the spectrum, the certificate could be issued by AD automatically for any computer joining the domain, with the subject name set of the FQDN of the computer. In this case, if the computer runs an OS deployment task sequence, it will be able to join the domain (since the task sequence has the domain join credentials) and it will automatically get a certificate from AD without the IT Admin doing anything. Obviously, this isn’t very secure.

At the other end of the spectrum, and IT Admin might have to physical visit the computer, verify its identity, and install the certificate from removable media once he has verified the identity of the computer. This is the most secure approach, but the hardest because of the manual steps required.

Any given customer will have to decide what approach meets their needs on the security/ease-of-use tradeoff.

In the case of PXE boot, the MAC address of the computer and/or the SMBIOS UUID of the computer are matched against entries in the ConfigMgr database. Assuming that a matching entry is found, the computer name from the database entry is sent back to the computer running the task sequence and that computer name is assigned, this is how SCCM recognize the machine in the case of PXE where not certificate is installed on the machine the machine is wiped off.