Managing conflicting records and duplicate GUIDs in Configuration Manager 2007

Thanks to elmunjo for this one!!!!!

General

ConfigMgr uses an ID that is generated on the Client to identify a machine inside the ConfigMgr hirarchy. This ID, also known as SMS GUID is generated during ConfigMgr Client installation.
An Algorithm, which combines the Timestamp (Time of ConfigMgr Client Installation) and the Universally Unique Identifier (UUID) is used to generate a unique Identifier.
A Client generates a new SMS GUID if the following things change


•the SMBIOS serial number
•the Machine SID
•the Hardware ID (see appendix)
There are several scenarios that may lead to problems with records in the ConfigMgr database.


Conflicting Records

Reinstallation of the operating system or changes to the Hardware components. In these cases a new SMS GUID is generated by the client and Conflicting Records are created. Conflicting records in ConfigMgr mean multiple DB records for one machine.
Conflicting records are created only in sites that run in ConfigMgr mixed mode. While in native mode, clients authenticate via certificates and thus when reinstalling a native mode client it gets a new certificate which contains the same subject (normally the Netbios computername).
Circumstances that trigger generation of a new Hardware ID:

1. some aspects accountable for the Hardware ID have changed.

There‘s 10 criteria monitored for Desktops, if 3 of them change, the ID also changes. For Notebooks 2 of 7 criteria have to change. The criteria are explained below.

2. the SMBios serial number has changed
3. the Computer SID has changed

In these cases the new HardwareID implies creation of a new SMS GUID what is why we get multiple entries in the ConfigMgr DB for just one machine.
The second scenario that leads to duplicate entries is the reinstallation of the operating system on existing hardware.

In both cases ConfigMgr reacts in the following way:
The Client is issued a new SCCM GUID, but the Hardware ID stays the same. A second record is created in the DB, a so called conflicting Record. SCCM 2007 can manage these Records automatically. In that case the old record is marked as obsolete and deleted according to the Delete obsolete Client Discovery Data Maintenance Task (Default= 7 days). If the site is not configured to handle conflicting records (Site Properties/ Advanced), both records are shown under the conflicting records node in the ConfigMgr console and the Administrator has to manually choose the method for managing these records. The easiest way would be a merge, which combines the old & new records to one while preserving all information of the older record.

How to Manage Conflicting Records for Configuration Manager Clients:
http://technet.microsoft.com/en-us/library/bb693963.aspx

Problems that can occur through conflicting records

Using the automatic method of ConfigMgr, a new record is always created and the old one is marked as obsolete. That means the history of the client is lost (Inventory etc.) and direct collection memberships won’t work anymore, as the collection contains the old client. Customers that make intense use of static collections cannot use this method. If you want to use merge mode this is always a manual action. Both records will stay under the node Conflicting Records. Management of this client is not possible until the administrator manually resolves the conflict.

Further methods for handling these records

Large ConfigMgr implementations will need other ways of handling these records. Microsoft has designed this procedure with respect of the security concerns. If the site was configured to automatically merge all conflicting records, it would be possible for an attacker to take over the identity of an already installed SCCM Client that is part of the ConfigMgr hierarchy. If you are not concerned with this kind of thoughts you can use a script to achieve auto merge functionality:
http://kristianfthomsen.spaces.live.com/blog/cns!59A30145A64F8A9F!156.entry

To avoid conflicting records during Wipe&Load installations, you can use the SMS Tool Tranguid. Tranguid can save the old GUID during the tasksequence before reinstalling the machine. Afterwards this file(Smscfg.ini ) is copied to thenew client which then uses the old GUID for communication with the ConfigMgr components.
http://technet.microsoft.com/en-us/sms/bb676787.aspx

Duplicate GUIDs

Cloning of Harddisks with installed ConfigMgr client, renaming a computer or DualBoot configurations may lead to duplicate GUIDs, which is absolutely not the same thing as conflicting records.

http://blogs.technet.com/carlossantiago/archive/2008/06/18/are-duplicate-guids-and-conflicting-records-the-same-thing.aspx

Duplicate GUIDs can occur in both site modes.

Duplicate GUIDs occur when
• Harddisks are duplicated with installed SCCM Client
• Computers are renamed with installed SCCM Client
• Computers are configured to dualboot, using the same PCName and having the SCCM Client installed in both configurations
In those cases multiple machines use the same record in the ConfigMgr database. ConfigMgr does not handle these records automatically. There is a predefined report showing possible conflicts:

Computers that may share the same SMS Unique ID (Nr. 71 assuming SP2)

Problems that can occur through duplicate GUIDs

Clients, that share one database record cannot be managed correctly. A collection will always show the client with the most recent discovery record. That means, the machine corresponding to the Collectionmember continiously changes. Thios is why software distribution to these clients will not be possible.

Methods for handling these records

As ConfigMgr anly offers a report to show the conflicts, but does not offer any means of remediation, the admin is forced to use other methods. There is a whitepaper from Microsoft for handling Duplicate GUIDs with SMS 2003 which is still valid:

http://www.microsoft.com/downloads/details.aspx?FamilyID=aaf6f10d-bd84-405e-9af3-b48ced1d7f2d&DisplayLang=en

The proposal is to generate a collection containing all DB records with duplicate GUIDs and then advertise a package that executes TRANGUID on the client and restarts the SMS Agent Host. The client will register with a new GUID. When the package has reached all machines, the collection will be empty.