How to remove lingering? object from Global Catalog?


  • Hi folks!

    I've faced the following issue: it seems there is a lingering object for one of the users stored in global catalog domain controllers across the forest.

    Symptoms: the forest consists of a number of domains. When I search one of the user on domain controllers in, using ADUC and search scope "Entire Directory", it returns only 1 user found. If I perform the same search on Domain controlers in other domains (domain2, domain3, domainX), it returns one more

    user : CN=username\0ACNF:6ed92073-799f-4d4a-b889-70f209cecaf6,CN=LostAndFound,DC=domain1,DC=contoso,DC=com

    This object can be browsed via adsiedit.msc and connect to the global catalog port: 3268

    This object exists on all GC domain controllers for all domains in the forest, except GCs in - the domain user belongs to.

    With the symptoms provided it looks like a lingering object in GC issue. But the question is how to remove it?

    I tried repadmin /removelingeringobjects - it doesn't find any lingering object in partition

    I tried ldp.exe as advised in article - ldp.exe shows the following error

    ***Call Modify...
    ldap_modify_s(ld, '(null)',[1] attrs);
    Error: Modify: Operations Error. <1>
    Server error: 00002095: SvcErr: DSID-03210D25, problem 5012 (DIR_ERROR), data 8420

    Error 0x2095 A directory service error has occurred.

    The situation looks weird, the domain where the "real", not GC, object was, doesn't have it. Neither in writable partition or GC. ALL other domain controllers in ALL of the other domains have the object in GC, but as the GC partition is read-only I cannot remove it.

    In some other threads I found the requesters finally gave up and rebuilt the DCs, but this is not an option for me to rebuild majority of the DCs - more than 200

    Could someone advise if there is any other way?

    Wednesday, December 21, 2016 8:46 AM

All replies

  • Anything logged in the directory service logs?  Any 1988 events?
    Wednesday, December 21, 2016 9:12 AM
  • nope

    The DCs having the object in GC partitions look absolutely fine

    • Edited by Igor Vyunov Wednesday, December 21, 2016 9:19 AM
    Wednesday, December 21, 2016 9:18 AM
  • Is strict replication enabled on all the DCs?
    Wednesday, December 21, 2016 9:22 AM
  • nope

    The DCs having the object in GC partitions look absolutely fine


     Check DC health and replication with "dcdiag","repadmin /replsum",also you should verfiy accessibility between the problematic dc and the others,you can check with PortQryUI;

    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    Wednesday, December 21, 2016 9:32 AM
  • Have you seen this?
    Wednesday, December 21, 2016 3:00 PM
  • Thank you PagyP, I didn't find this article before and it looks really promising!

    Appreciate your help!

    Thursday, December 22, 2016 1:01 PM
  • Hi Igor,

    Please refer below article which talks abt how to remove lingering objects using GUI tool.

    Regards, Nidhin.CK

    Thursday, December 22, 2016 1:11 PM
  • Hi folks,

    We've found only one working solution for cases, when lingering objects are located in Global catalog naming contexts and aren't located in writable domain partition.

    The solution is to re-build the domain partition in Global catalog, using the clean source - writable partition or clean GC using command:

    “repadmin /rehost %IMPACTED_DC_NAME” "DC=corp,DC=contoso,DC=com" %CLEAN_WRITABLE_DC_OR_GC_NAME%”

    During the process of rehosting, GC on server is available and functional.

    After rebuilding GC partition, it can't replicate with "dirty" replication partners.


    Friday, January 26, 2018 9:15 AM