none
Duplicate Records

    Question

  • Hi. I am having a intermittent issue with duplicate records showing up for computers only. The issue seems to be attributed to the different discovery methods that SCCM uses. I've read many different 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 that I can discern.

    I have a single primary site that uses discovery. My hierarchy is R3. Here are my discovery settings:
    AD System Discovery: 2days (5min delta)
    AD System Group Discovery: 15minutes (5min delta)
    Heartbeat Discovery:8 hours
    Network Discovery:Disabled

    The basic problem is when I build a new computer sometimes it will do as follows:

    1. Computer is built through OSD – Once built 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 <null> for most of the fields including the SMSGUID, but it does have  the correct AD Group/OU information (i.e. this record was created directly from AD/DNS but is in no way associated with the computer record already in SCCM).
    4. Further AD Sys Grp Discoveries only update the new record that isn’t linked to the actual client
    5. The original record (that is 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 per normal.

    This problem is far from consistent. Recently I built eight computers PC01 – PC08 at exactly the same time, out of them only PC02 experienced this problem. The original record for PC02 was created on 11/03/2011 4:53:56pm via the DDR/Heartbeat Discovery, this record was correctly processing AD Sys Grp Discoveries. Then another record for PC02 was created on 12/03/2011 12:15:35 am via AD Sys Disc. At this point 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" record 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 what I can do to stop it happening in the first place.

    Cheers


    William Eriepa | New Zealand
    Wednesday, April 6, 2011 11:09 PM

Answers

  • Hello - I have seen this issue....The below is the workaround provided by MS?

    May be you can give a try?

    This occurs due to the discovery data manager mechanism which 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 1 result is returned. Any subsequent AD discovery will then update the NULL or inactive entry in the database instead of the active entry.

     

    Ms is aware of this issue and this has been bugged. The workarounds available at the moment are to avoid the duplication in the first place or delete the duplicate entries from the database using the following collection query which will identify clients that are duplicate records and are not active 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 these duplicates identified in the collection have been deleted all future AD discovery methods will update the correct entry in the database.

     

    Please follow the following:

     

    1. Create a collection for colleting the duplicate system with 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

     

    1. Once the collection is created. Right click and select delete special.
    2. This will delete all the systems which are populated in this collection.

    Anoop C Nair - This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Will Eriepa Friday, April 8, 2011 2:31 AM
    Thursday, April 7, 2011 5:55 AM
  • So as far as you know there's no way to prevent this from occuring in the first place?

    Nope, there is no permanent solution or hot fix for this (it seems).

    Do you have this problem in your environment Anoop?

    Yes

     


    Anoop C Nair - This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Will Eriepa Friday, April 8, 2011 2:31 AM
    Thursday, April 7, 2011 6:13 AM

All replies

  • Hello - I have seen this issue....The below is the workaround provided by MS?

    May be you can give a try?

    This occurs due to the discovery data manager mechanism which 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 1 result is returned. Any subsequent AD discovery will then update the NULL or inactive entry in the database instead of the active entry.

     

    Ms is aware of this issue and this has been bugged. The workarounds available at the moment are to avoid the duplication in the first place or delete the duplicate entries from the database using the following collection query which will identify clients that are duplicate records and are not active 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 these duplicates identified in the collection have been deleted all future AD discovery methods will update the correct entry in the database.

     

    Please follow the following:

     

    1. Create a collection for colleting the duplicate system with 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

     

    1. Once the collection is created. Right click and select delete special.
    2. This will delete all the systems which are populated in this collection.

    Anoop C Nair - This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Will Eriepa Friday, April 8, 2011 2:31 AM
    Thursday, April 7, 2011 5:55 AM
  • Thanks Anoop. I have been identifying duplicate records through a report I created, and then deleting the NULL entries based on that.

    I've seen different posts before on collections that are meant to query and add the "correct" duplicate entry so that it can be easily deleted, but none of them have worked before. I will give this a try though as it is much more efficient to delete straight from a collection rather than search based on a report :)

    So as far as you know there's no way to prevent this from occuring in the first place?

    This occurs due to the discovery data manager mechanism which 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 1 result is returned
    This is true, but it doesn't explain why another entry is created in the first place.

    Do you have this problem in your environment Anoop?

    Many Thanks.


    William Eriepa | New Zealand
    Thursday, April 7, 2011 6:07 AM
  • So as far as you know there's no way to prevent this from occuring in the first place?

    Nope, there is no permanent solution or hot fix for this (it seems).

    Do you have this problem in your environment Anoop?

    Yes

     


    Anoop C Nair - This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Will Eriepa Friday, April 8, 2011 2:31 AM
    Thursday, April 7, 2011 6:13 AM
  • You can also take a look at this KB article explaining How to locate and clean Advanced Client Duplicate GUIDs with collections

    http://support.microsoft.com/kb/837374 

     


    //Eswar Koneti @ www.eskonr.com
    Thursday, April 7, 2011 7:54 AM
  • Thanks Eswar, but my problem isn't with duplicate GUIDS - only one record ever has a GUID, the other is always NULL as it was from AD discovery only and not linked to any real client.

    Cheers


    William Eriepa | New Zealand
    Thursday, April 7, 2011 8:52 PM
  • Thanks Anoop that collection worked a charm. The collection has ALL the duplicate records and it only includes the "right" records that need to be deleted. That will help me a lot in treating this problem. Thanks
    William Eriepa | New Zealand
    Friday, April 8, 2011 2:30 AM
  • Suggest turning off Delta Discovery on AD System Discovery... it is the cause of adding these duplicate records.

    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 with "normal" AD System Disc... so only run this once a day after hours  (when you will not be imaging).

    And a note re having Delta on your AD System Group Discovery... it is not going to find Computers newly added to groups... so I'd be turning that off too.

    http://blogs.technet.com/b/configurationmgr/archive/2012/03/27/machine-added-to-a-configmgr-group-is-not-captured-during-the-delta-discovery-process.aspx

    Running your AD System Group Discovery every 15 minutes seems a bit excessive.  If you have Collections querying AD group membership, unless you also have your Collection update schedules set this low... then not sure of the benefit of every 15mins.

    Shane

    (Please "Propose as answer" / "Mark as answer" / "Vote as helpful" if appropriate)

    Saturday, June 16, 2012 6:37 AM
  • Does this issue still exist in CM12?
    Thursday, September 25, 2014 5:11 PM