none
RepAdmin /showutdvec objects RRS feed

  • Question

  • I'm seeing some unnamed objects listed with the showutdvec command, and some that say "(retired)".  I think replication is working, I'm not seeing any errors or problems.  Are these old DC objects that were not demoted properly?


    repadmin.exe /showutdvec dc1 "DC=domain,DC=com"

    Caching GUIDs.
    ..
    Default-First-Site-Name\DC3         @ USN    953190 @ Time 2010-10-02 07:30:53
    224f7dd6-df2f-4db2-9a78-09551e0020e6 @ USN    413657 @ Time 2004-12-20 08:16:47
    3397fa51-a2a7-4d15-b5c5-408468e4019d @ USN    319627 @ Time 2005-02-06 21:25:54
    3b8ee1fb-ca6c-417c-8d2a-9f20e0a3c11b @ USN    374539 @ Time 2005-05-25 23:20:03
    542558e4-5395-4b14-8dc8-3897fdc4a3c0 @ USN    103201 @ Time 2003-09-07 10:20:32
    584cf10a-2932-4ff2-b27d-bcc8170dc35f @ USN    282722 @ Time (unknown)
    Default-First-Site-Name\DC2     @ USN   6448530 @ Time 2010-10-02 07:30:12
    Default-First-Site-Name\DC1       @ USN   5741197 @ Time 2010-10-02 07:30:28
    8b9866e3-e7a1-4f65-939e-bd580585ec28 @ USN    626041 @ Time 2010-06-08 08:57:31
    Default-First-Site-Name\DC1 (retired) @ USN   4324397 @ Time 2010-01-17 14:33:30
    Default-First-Site-Name\DC4         @ USN   1704539 @ Time 2010-10-02 07:30:27
    Default-First-Site-Name\DC1 (retired) @ USN   4673786 @ Time 2010-05-01 15:41:19
    Default-First-Site-Name\DC5         @ USN    764462 @ Time 2010-10-02 07:29:57
    ddbe4574-592d-4f22-b1ce-09a926f9ffd1 @ USN    373391 @ Time 2003-07-20 10:55:20

     

    If any these are not needed, can I safely do some cleanup so they aren't there?

    Thanks!

     

    Saturday, October 2, 2010 2:13 PM

Answers

  • Not sure what you mean by "... this command on 3 different domains shows 7 objects with a GUID, they all 3 just happen to have 3 demoted ...". In case you didnt know, this command is used to get an idea of how upto date the particular partition on a DC is with regards to other replicas. Obviously each DC's NTDS.DIT is made up of a several partitions. at the very least they include configuration, schema and a domain partition.

    repadmin.exe /showutdvec dc1 "DC=domain,DC=com"
    Note above I have bolded the partition that you are checking to see here. The DC1 you provide as an argument is the DC you are interested in checking to see how up to date it is.

    Default-First-Site-Name\DC3         @ USN    953190 @ Time 2010-10-02 07:30:53

    The above line is saying that DC1 is aware of all originating changes that occurred directly on DC3 (belonging to the default-first-site-name site) up to USN 953190. Update 953190 happened at 2010-10-02 07:30:53. if DC3 has done some originating changes since then, chances are DC1 hasnt received them yet. You'd know if DC3 has done more changes on itself for the "DC=domain,DC=com" partition by running the /showutdvec command as above but replacing dc1 with dc3 to see its view of its own partition (which would give details of itself and originating changes it received from others).

    The /showutdvec returns data of each entry as a GUID. Its specifically returning the invocationID. The invocationID is the GUID of the NTDS.DIT which is unique to each DC. This changes when the server is restored. hence the "retired" entries. When it cant resolve it to a sensible DC (that owns that ntds.dit) it merely shows the GUID.

    http://msdn.microsoft.com/en-us/library/cc228406(v=PROT.13).aspx has details of UTDV vector (showutdvec)

    http://blogs.msdn.com/b/brettsh/archive/2006/02/09/528708.aspx has some details of this repadmin.exe behaviour of translating invocationID.

    See http://technet.microsoft.com/en-us/library/cc772726(WS.10).aspx for how AD replication works which explains propagation dampenng.


    repadmin.exe help in Vista and above is best. I would do repadmin /?:showutdvec for more details. Else see http://www.microsoft.com/downloads/en/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en&tm 

    its good to find admins that do house keeping in AD :). I dont often run into admins with that interest. AFAIK I dont think you can delete these entries because AD needs it to decide what to or not replicate (i.e. propagation dampening)

    Was trying to be brief previously. hope the information helps. I dont hang out here often. So please excuse if further replies are delayed. Moderators or MVPs will help I am sure.


    M@
    • Marked as answer by Steve Lynch 2 Tuesday, October 5, 2010 12:21 PM
    Sunday, October 3, 2010 10:54 PM
  • The GUID based entries are those that were demoted (clean or force demotion doesnt matter). The "retired" are those that were restored. So as per above two retired entries, DC1 was likely restored twice from AD backups.

    You cant remove these entries. Why would you want to anyway? These are for the benefit of domain controllers internal operations (such as replication propagation dampening)


    M@
    • Marked as answer by Steve Lynch 2 Tuesday, October 5, 2010 12:21 PM
    Sunday, October 3, 2010 6:03 PM

All replies

  • has any DCs been removed from the forest by not using
    dcpromo with successfully demote?

    Have a look at this articles:

    HOW TO: Troubleshoot Intra-Site Replication Failures
    http://support.microsoft.com/default.aspx?scid=kb;en-us;249256
    How to remove data in Active Directory after an unsuccessful domain
    controller demotion:
    http://support.microsoft.com/default.aspx?scid=kb;en-us;249256

    DO you see any event ids related to replication in the Event Viewer ?


    http://www.virmansec.com/blogs/skhairuddin
    Saturday, October 2, 2010 2:39 PM
  • Thanks for the reply.

    "has any DCs been removed from the forest by not using
    dcpromo with successfully demote?"

    -- Not that I know of, but that's why I posted this and asked the question "Are these old DC objects that were not demoted properly?"

    "DO you see any event ids related to replication in the Event Viewer ?"
    -- No errors in the event logs.  "repadmin.exe /replsummary" and "repadmin.exe /showrepl" show no problems.  I made a change to a user account and the change immediately showed up on all 5 domain controllers.

     

    Saturday, October 2, 2010 3:36 PM
  • Verify the AD database using NTDSutil to make that name doesn’t existing in AD. 

    http://technet.microsoft.com/en-us/library/cc736378(WS.10).aspx

    You should be able to see all DCs using the following command:

    list servers in site


    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX

    Blogs - http://blogs.sivarajan.com/
    Articles - http://www.sivarajan.com/publications.html
    Twitter: @santhosh_sivara - http://twitter.com/santhosh_sivara

    This posting is provided AS IS with no warranties, and confers no rights.
    Saturday, October 2, 2010 6:45 PM
    Moderator
  • NTDSutil "list servers in site" only shows the 5 domain controllers that are active.

    I've ran the "repadmin.exe /showutdvec" command on 3 different domains, and in all 3 it shows 7 objects without a name, just GUIDs or whatever they are.  So maybe it's normal, is anyone else seeing these objects?  When you run /showutdvec do you only see the current/active DCs?

     

    Sunday, October 3, 2010 3:44 PM
  • The GUID based entries are those that were demoted (clean or force demotion doesnt matter). The "retired" are those that were restored. So as per above two retired entries, DC1 was likely restored twice from AD backups.

    You cant remove these entries. Why would you want to anyway? These are for the benefit of domain controllers internal operations (such as replication propagation dampening)


    M@
    • Marked as answer by Steve Lynch 2 Tuesday, October 5, 2010 12:21 PM
    Sunday, October 3, 2010 6:03 PM
  • Thanks.  So is it just a coincidence that this command on 3 different domains shows 7 objects with a GUID, they all 3 just happen to have 7 demoted DCs?  I don't have access to any other domains to compare.

    "Why would you want to anyway?" - well, the same reason you would clean your house or clean your car - so it's clean and nice to look at.  But if its not safe to delete these I will leave them, that's why I asked here before deleting them.  It sounds like you know what you're talking about, but without any links you could just be guessing.

    I'll do some searching/reading on "propagation dampening".

     

    Sunday, October 3, 2010 8:33 PM
  • Not sure what you mean by "... this command on 3 different domains shows 7 objects with a GUID, they all 3 just happen to have 3 demoted ...". In case you didnt know, this command is used to get an idea of how upto date the particular partition on a DC is with regards to other replicas. Obviously each DC's NTDS.DIT is made up of a several partitions. at the very least they include configuration, schema and a domain partition.

    repadmin.exe /showutdvec dc1 "DC=domain,DC=com"
    Note above I have bolded the partition that you are checking to see here. The DC1 you provide as an argument is the DC you are interested in checking to see how up to date it is.

    Default-First-Site-Name\DC3         @ USN    953190 @ Time 2010-10-02 07:30:53

    The above line is saying that DC1 is aware of all originating changes that occurred directly on DC3 (belonging to the default-first-site-name site) up to USN 953190. Update 953190 happened at 2010-10-02 07:30:53. if DC3 has done some originating changes since then, chances are DC1 hasnt received them yet. You'd know if DC3 has done more changes on itself for the "DC=domain,DC=com" partition by running the /showutdvec command as above but replacing dc1 with dc3 to see its view of its own partition (which would give details of itself and originating changes it received from others).

    The /showutdvec returns data of each entry as a GUID. Its specifically returning the invocationID. The invocationID is the GUID of the NTDS.DIT which is unique to each DC. This changes when the server is restored. hence the "retired" entries. When it cant resolve it to a sensible DC (that owns that ntds.dit) it merely shows the GUID.

    http://msdn.microsoft.com/en-us/library/cc228406(v=PROT.13).aspx has details of UTDV vector (showutdvec)

    http://blogs.msdn.com/b/brettsh/archive/2006/02/09/528708.aspx has some details of this repadmin.exe behaviour of translating invocationID.

    See http://technet.microsoft.com/en-us/library/cc772726(WS.10).aspx for how AD replication works which explains propagation dampenng.


    repadmin.exe help in Vista and above is best. I would do repadmin /?:showutdvec for more details. Else see http://www.microsoft.com/downloads/en/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en&tm 

    its good to find admins that do house keeping in AD :). I dont often run into admins with that interest. AFAIK I dont think you can delete these entries because AD needs it to decide what to or not replicate (i.e. propagation dampening)

    Was trying to be brief previously. hope the information helps. I dont hang out here often. So please excuse if further replies are delayed. Moderators or MVPs will help I am sure.


    M@
    • Marked as answer by Steve Lynch 2 Tuesday, October 5, 2010 12:21 PM
    Sunday, October 3, 2010 10:54 PM
  • Good info, thanks for your time.  What I meant by 3 different domains was simple, a lab domain and 2 different production domains.  They all show the active DCs and 7 GUIDs, I thought that was odd but I guess its just a coincidence.

     

    This seems to be the best info yet:

    Server Object GUID (DSA GUID) and Server Database GUID (Invocation ID)

    The server object that represents a domain controller in the Sites container of the configuration directory partition has a globally unique identifier (GUID) that identifies it to the replication system as a domain controller. This GUID, called the DSA (Directory System Agent) GUID, is used in USNs to track originating updates. It is also used by domain controllers to locate replication partners. The DSA GUID is the GUID of the NTDS Settings object (class nTDSDSA), which is a child object of the server object. Its value is stored in the objectGUID attribute of the NTDS Settings object.

    The DSA GUID is created when Active Directory is initially installed on the domain controller and destroyed only if Active Directory is removed from the domain controller. The DSA GUID ensures that the DSA remains recognizable when a domain controller is renamed. The DSA GUID is not affected by the Active Directory restore process.

    The Active Directory database has its own GUID, which the DSA uses to identify the database instance (version of the database). The database GUID is stored in the invocationId attribute on the NTDS Settings object. Unlike the DSA GUID, which never changes for the lifetime of the domain controller, the invocation ID is changed during an Active Directory restore process to ensure replication consistency. For more information about replication following a restore process, see “Active Directory Replication on a Restored Domain Controller” later in this section.

    On domain controllers that are running Windows Server 2003, the invocation ID also changes when an application directory partition is removed from or added to the domain controller.

    Determining Changes to Replicate: Update Sequence Numbers

    A source domain controller uses USNs to determine what changes have already been received by a destination domain controller that is requesting changes. The destination domain controller uses USNs to determine what changes it needs to request.

    The current USN is a 64-bit counter that is maintained by each Active Directory domain controller as the highestCommittedUsn attribute on the rootDSE object. At the start of each update transaction (originating or replicated), the domain controller increments its current USN and associates this new value with the update request.

    Note

    • The rootDSE (DSA-specific Entry) represents the top of the logical namespace for one domain controller. RootDSE has no hierarchical name or schema class, but it does have a set of attributes that identify the contents of a given domain controller.

    The current USN value is stored on an updated object as follows:

    • Local USN: The USN for the update is stored in the metadata of each attribute that is changed by the update as the local USN of that attribute (originating and replicated writes). As the name implies, this value is local to the domain controller where the change occurs.
    • uSNChanged: The maximum local USN among all of an object’s attributes is stored as the object’s uSNChanged attribute (originating and replicated writes). The uSNChanged attribute is indexed, which allows objects to be enumerated efficiently in the order of their most recent attribute write.

      Note

      • When the forest functional level is Windows Server 2003 or Windows Server 2003 interim, discrete values of linked multivalued attributes can be updated individually. In this case, there is a uSNChanged associated with each link in addition to the uSNChanged associated with each object. Therefore, updates to individual values of linked multivalued attributes do not affect the local USN, only the uSNChanged attribute on the object.
    • Originating USN: For an originating write only, the update’s USN value is stored with each updated attribute as the originating USN of that attribute. Unlike the local USN and uSNChanged, the originating USN is replicated with the attribute’s value.

     

    Tuesday, October 5, 2010 1:57 AM