SCCM How to Resolve Duplicate or Conflict Record Issues ConfigMgr

SCCM How to Resolve Duplicate or Conflict Record Issues ConfigMgr. I have seen many duplicate record-related issues faced by many people in the Forums. William Eriepa explained the problem in the TechNet thread below.

Records that have the same name, different GUID, and various hardware IDs are called Duplicate or Conflict Records. This is usually caused by a machine that already has a record in SCCM, is modified after its initial record creation and generates a new GUID.

ISSUE – How to Resolve Duplicate or Conflict Record Issues

ISSUE (Credits to William Eriepa) – “Hi. I have an intermittent problem with duplicate records showing up only on computers. The issue seems to be attributed to the different discovery methods that SCCM uses.

• ConfigMgr Reports Power Management | Default
• How To Disable SCCM Application Deployment | ConfigMgr
• Learn How To ConfigMgr SCCM Merge Obsolete Duplicate Records

I’ve read many posts on Technet and other sites but have been unable to find a solution. I’ve checked the related discovery logs and haven’t seen any discovery errors or issues I can discern.

I have a single primary site that uses discovery. My hierarchy is R3. Here are my discovery settings:

Discovery	Settings
AD System Discovery	2days (5min delta)
AD System Group Discovery	15 minutes (5min delta)
Heartbeat Discovery	8 hours
Network Discovery	Disabled

Duplicate or Conflict Record Issues

The Fundamental Problem is when I Build a New Computer, and sometimes it will do as follows:

1. The computer is built through OSD. Once built, the SCCM client sends a DDR to the Site Server, and a record is created for it.

2. Up to 15 minutes later, when AD Sys Grp Disc runs, the record is populated with the correct AD Group/OU information, etc.

3. Up to 2 days later, when AD Sys Disc runs, a new record is created for the same computer. This record has for most of the fields, including the SMSGUID. Still, it does have the correct AD Group/OU information (i.e., this record was created directly from AD/DNS but is not associated with the computer record already in SCCM).

4. Further, AD Sys Grp Discoveries only updates the new record that isn’t linked to the client.

5. The original record (linked to the actual client) loses the AD Group/OU information it had and is no longer updated by further AD Sys Grp Discoveries. Heartbeat discoveries continue to work as usual.

This problem is far from consistent. Recently, I built eight computers, PC01 – PC08, at the same time, but only PC02 experienced this problem. The original record for PC02 was created on 11/03/2011 at 4:53:56pm via the DDR/Heartbeat Discovery.

This record was correctly processing AD Sys Grp Discoveries. Then, another form for PC02 was created on 12/03/2011 at 12:15:35 am via AD Sys Disc. The original record lost its AD Group/OU associations and no longer processed AD Sys Grp Disc.

Deleting the “new” record created by AD Sys Disc results in the “original” form getting the correct AD Group/OU information during the next AD Sys Grp Discovery. So, I do have a way to treat this problem, but I would like to find out how to stop it from happening in the first place.

Workaround – SCCM How to Resolve Duplicate or Conflict Record Issues ConfigMgr

Due to the discovery data manager mechanism, Duplicate Records runs a query and sorts the results by date. It will update the most recent returned result rather than the active result if more than one result is returned.

Any subsequent AD discovery will update the NULL or inactive entry in the database instead of the active entry.

This is a known issue with Microsoft. A workaround is available to remove the duplicate records. The below-mentioned query will identify duplicate records of clients:

Select R.ResourceID,R.ResourceType,R.Name,R.SMSUniqueIdentifier,R.ResourceDomainORWorkgroup,R.Client from SMS_R_System as r full join SMS_R_System as s1 on s1.ResourceId = r.ResourceId full join SMS_R_System as s2 on s2.Name = s1.Name where s1.Name = s2.Name and s1.ResourceId != s2.ResourceId and R.Client = null

Once those duplicates are identified and fetched into the collection, we can delete them using the following process. All future AD group discoveries will update the correct record in the database.

1. Create a collection for collecting the duplicate system with a NULL record. Please use the below query.

Select R.ResourceID,R.ResourceType,R.Name,R.SMSUniqueIdentifier,R.ResourceDomainORWorkgroup,R.Client from SMS_R_System as r full join SMS_R_System as s1 on s1.ResourceId = r.ResourceId full join SMS_R_System as s2 on s2.Name = s1.Name where s1.Name = s2.Name and s1.ResourceId != s2.ResourceId and R.Client = null

2. Once the collection is created and records are populated. Right-click and select Delete Special.
3. This will delete all the populated systems in this collection.

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Anoop C Nair is Microsoft MVP! He is a Device Management Admin with more than 20 years of experience (calculation done in 2021) in IT. He is a Blogger, Speaker, and Local User Group HTMD Community leader. His primary focus is Device Management technologies like SCCM 2012, Current Branch, and Intune. He writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc.