Problem SCCM Records- http://nikifoster.wordpress.com/2012/05/25/problem-sccm-records/
So I was having a discussion with a colleague today about records in SCCM and the different problems we have (or I have previously had) with them!
There is quite a bit of information on the net regarding records but a lot seem to be a bit misleading, probably due to the small amount of official Microsoft information, as well as the wording being a inaccurate.
If you’re reading this, then chances are you’ve read this – http://elmunjo.blogspot.com/2010/01/managing-conflicting-records-and.html – and although this is good info (I’ve copied some of it in to this post) I actually believe it is only part correct. Specifically, I think the “conflicting records” section is incorrect.
This post is an attempt to clarify the problems and I have classified them into 3 categories, based on my own experiences. I thought it important to seperate the different types of records due to the different behaviour that occurs with each one. If you think you have something to add or think I have something wrong here, please feel free to comment and I will try and integrate it into the article.
Defined as: Records that have either the same or different name, different GUID and the same hardware ID.
This is normally caused by rebuilding the exact same machine, that already has a record in SCCM, with the same name. In this instance a second record appears in SCCM, with the same name and the same hardware ID.
You can configure SCCM to deal with these types of records automatically ( but that brings its own set a challenges! In this 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. It can also be scripted, check out this excellent post for more info – http://ccmexec.com/2011/03/merging-obsolete-records-in-configuration-manager-2007/
Defined as: Records that have the same name, different GUID and different hardware ID.
This is normally caused by a machine, after already having a record in SCCM, having its hardware ID changed and so getting a new GUID. 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.
2.The SMBios serial number has changed
3.The Computer SID has changed
So for example, if you image a machine, then remove the HDD and place into another machine, even of the same type, the machine ID will change, a new GUID will be generated and you will see a duplicate record in SCCM.
There are also other scenarios where you will see duplicate records, for example: http://blogs.technet.com/b/configmgrteam/archive/2011/09/09/known-issue-and-workaround-duplicate-records-when-you-use-unknown-computer-support-with-active-directory-delta-discovery.aspx
How to deal with these? Well you can either delete them or script it to merge them. I’m afraid I dont have a script you can use but I do know the script used to deal with conflicting records WON’T WORK!
Defined as: All records with the same GUID
In this case multiple machines use the same record in the ConfigMgr database. Duplicate GUIDs occur when:
1.Harddisks are duplicated with installed SCCM Client
2.Computers are renamed with installed SCCM
3.Client Computers are configured to dualboot, using the same PC name and having the SCCM Client installed in both configurations.
Clients, that share one database record cannot be managed correctly. A collection will always show the client with the most recent discovery record and that means the machine corresponding to the collection member continiously changes. This means software (or even OSs) meant for one computer could potentially be advertised to a completely different one. Not good!
SCCM 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