I end up with double DDR in sccm after machine is been rebuilt one active and another is inactive, is this a known issue, how do you deal with it, because I have to go back, delete the inactive and assign the active to the collections, lots of manual steps is there a way around it. Thanks

If you are talking about the obsolete machine. This is because you did a bare metal reimage of the machine. You booted from the Boot Media and imaged as a new computer. If you did a reimage/refresh you won't have this problem and the machine should stay in all the collections. http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com

Hi Benmot, I think you are talking about duplicate/conflicting records in SCCM, right? Actually, duplicate and conflicting records are not the same thing in SCCM. ConfigMgr uses an ID that is generated on the client to identify a machine inside the ConfigMgr hierarchy. This ID, also known as SCCM GUID is generated during ConfigMgr Client installation. A Client generates a new SCCM GUID if the following things change: the SMBIOS serial numberthe Machine SIDthe Hardware ID Conflicting Records: Conflicting Records in ConfigMgr mean multiple DB records for one machine. Reinstallation of the operating system or changes to the hardware components will generate conflicting records.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 computer name). In cases, new hardware ID implies creation of a new SCCM GUID what is why we get multiple entries in the ConfigMgr DB for just on machine. SCCM can manage conflicting records automatically. In that case the old record is marked as obsolete and deleted according to the Delete obsolete Client Discovery Data Maintenance Task. 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 chosose 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 Duplicate GUIDs: As I known, cloning of hard disks with installed ConfigMgr client, renaming a computer or DualBoot configurations may lead to duplicate GUIDs. In those cases, multiple machines use the same record in the ConfigMgr Database. ConfigMgr does not handle these records automatically. These is a white-paper for handling duplicate GUIDs with SMS 2003 which is still valid: http://www.microsoft.com/en-us/download/details.aspx?id=17957 Hope this will help. Thanks

I'm talking about absolete records, When the machine is built I end up with two records one active and the other is absolete. I did not built the machine as a bare metal I imported the MAC and SM BIOS GUID in to the SCCM and added the machine to the Collection where I have the Task Sequence Advertised. So pfysically the machine did not exist yet but the information was imported and when the machine is build after AD discovery I end up with two Conflicting DDR's

If you imported the MAC into the database then it is a bare metal machine. the problem appears to be that the machine is imaging and the Discovery is finding it at the same time. When you are done you can't be in there twice. You can see about changing your discovery to a time when you are not imaging, say 2AM or such. Or it could be a heart beat getting there...http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com

I dont think its Discovery because I do have discovery running once a day at 2am. But the heart beat how and what do I do about that

Here's the MS link for what "SMS Marshall" refered to... 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 We've also seen this occur with "normal" (non-delta) AD System Discovery... so we only run AD System Disc once a day after hours (like Matt said... early AM). But re 2 records, 1 obsolete and 1 not... refer to Eswar's post... and note what the link says... must change setting to "Manually resolve conflicting records". Shane Thx Shane

Pleasure ;-)