Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2006-12-09) DC-GUIDs And Invocation IDs

Posted by Jorge on 2006-12-09


Within Active Directory, each domain controller has two very important IDs, which are called the "DC-GUID" and "Invocation ID". (DC-GUID can also be called the DSA-GUID, where DSA = Directory Service Agent. However DC-GUID is more common and you will see in the output below). Those domain controller IDs are used by the replication mechanism in Active Directory.

DC-GUID:

  • ID for the domain controller itself
  • Never changes during the lifetime of a domain controller.
  • Created during promotion and destroyed during demotion
  • Stored within the attribute called "objectGUID" on the "NTDS Settings" object (which identifies the DC within AD). Same GUID is registered in DNS in the "_MSDCS.<ForestRootDomain>" DNS zone as a CNAME resource record so that other DCs can replicate with it
  • Used to identify replication partners amongst each other

Invocation ID:

  • ID for the database instance on the domain controller
  • Initially EXACTLY the same as the DC-GUID for the first DC in the AD forest until it changes (see below when). For all other DCs in the AD forest it will change right away during the promotion to a DC. After that it changes as mentioned in the next bullit.
  • Changes during the lifetime of a domain controller when the domain controller has been restored from a VALID backup using a VALID backup method and tool OR when a writable (application) partition has been instantiated (added or re-added) on the domain controller (re-added means remove existing partition from the DB and add it back later on)
    REMARK:
  • Created the first time during promotion and changes after restore, NC instantiating, demotion, etc.
  • Stored within the attribute called "invocationID" on the "NTDS Settings" object (which identifies the DC within AD)
  • OLD "invocationIDs" are stored in the attribute called "retiredReplDSASignatures" on the "NTDS Settings" object (which identifies the DC within AD)
  • Used to identify database instances on domain controllers where changes CAN/WILL originate for a certain naming context (partition)

For Active Directory replication, domain controllers only care about the DC-GUID of their inbound replication partners, but care about ALL the invocation IDs of previous and current database instances that host a writable naming context (partition). Domain controllers with a certain writable partition DO NOT care about the invocation ID of another domain controller hosting a read-only version of the same naming context. Why? Because changes DO NOT originate on read-only versions of naming contexts. Read-only versions of naming contexts are hosted by global catalogs hosting some naming context from another domain AND in addition within Windows Longhorn Server by Read-Only domain controllers within the same domain. I will show this later on.

OK, so how to know what those IDs are of some DC without using ADSIEDIT.MSC or LDP? That easy, you can use REPADMIN, REPLMON and every tool that you can use to query Active Directory, like ADFIND from Joe Richards (great tool by the way!).

To find the CURRENT DC-GUID and Invocation ID from some domain controller (see output below as example):

  • REPADMIN /SHOWREPL <FQDN DC>
    • When no DC name is provided it will target the localhost

clip_image001[4]

clip_image002

To find the DC that belongs to a certain Invocation ID (see output below as example):

  • ADFIND -config -rb "CN=Sites" -s subtree -binenc -f "(invocationId={{GUID:<guid>}})" -dn

image

To find the RETIRED Invocation IDs for some domain controller (see output below as example):

  • ADFIND -b "<DN of DC’s NTDS Settings object>" -s base -tdc retiredReplDSASignatures

image

To find the RETIRED Invocation IDs for all domain controllers that have at least one (see output below as example):

  • ADFIND -config -rb "CN=Sites" -s subtree -f "(&(objectClass=nTDSDSA)(retiredReplDSASignatures=*))" -tdc retiredReplDSASignatures

image

To find the DC that belongs to a certain RETIRED Invocation ID (see output below as example):

  • ADFIND -config -rb "CN=Sites" -s subtree -binenc -f "(retiredReplDSASignatures=*{{GUID:<guid>}}*)" -dn

image

So lets look at the example below and see how replication works between the domain controllers in the picture.

image

So for the example above lets define the following info for the replication of the configuration naming context (partition):

  • CHLDDC001 <—replication—> ROOTDC001 (two-way)
  • ROOTDC001 <—replication—> ROOTDC002 (two-way)

When ROOTDC002 wants to replicate information in the configuration naming context (partition) after it received a change notification from ROOTDC001, it "asks" ROOTDC001 something like:

  • The last time I (ROOTDC002) replicated from you (ROOTDC001), I received all the updates until your (ROOTDC001) highest committed USN (high watermark) "X". So I (ROOTDC002) now want everything above highest committed USN (high watermark) "X", whereas I (ROOTDC002) already know about the updates until up-to-dateness vector USN "A" for CHLDDC001, up-to-dateness vector USN "B" for ROOTDC001 and up-to-dateness vector USN "C" for ROOTDC002.
  • ROOTDC001 checks for all the registered updates on ROOTDC001 above USN "X" and filters out all the updates that originated on CHLDDC001 until USN "A", all the updates that originated on ROOTDC001 until USN "B" and all the updates that originated on ROOTDC002 until USN "B".
  • Every other update that remains is replicated from ROOTDC001 to ROOTDC002.
  • As you can see ROOTDC002 also sents its own latest up-to-dateness vector USN to ROOTDC001 so that anything that originated on ROOTDC002 and has replicated to ROOTDC001, is not replicated back to ROOTDC002. That is called propagation dampening, which prevents the continous replication between the same domain controllers for the same update

So for the example above lets define the following info for the replication of the domain naming context (partition) for the domain ADCORP.LAN:

  • All the DCs (ROOTDC001, ROOTDC002 and CHLDDC001) are GCs
  • CHLDDC001 <—replication—- ROOTDC001 (one-way only!)
  • ROOTDC001 <—replication—> ROOTDC002 (two-way)

When ROOTDC002 wants to replicate information in the domain naming context (partition) for the domain ADCORP.LAN after it received a change notification from ROOTDC001, it "asks" ROOTDC001 something like:

  • The last time I (ROOTDC002) replicated fro
    m you (ROOTDC001), I received all the updates until your (ROOTDC001) highest committed USN (high watermark) "Y". So I (ROOTDC002) now want everything above highest committed USN (high watermark) "Y", whereas I (ROOTDC002) already know about the updates until up-to-dateness vector USN "D" for ROOTDC001 and up-to-dateness vector USN "E" for ROOTDC002. As you can see it does not mention the up-to-dateness vector of CHLDDC001 for the domain naming context for the domain ADCORP.LAN…Why? Answer: CHLDDC001 does not have a up-to-dateness vector for the domain naming context for the domain ADCORP.LAN because its hosted naming context is a read-only version where updates cannot originated. And because it cannot originate there it does not need to ask for it!
  • ROOTDC001 checks for all the registered updates on ROOTDC001 above USN "Y" and filters out all the updates that originated on ROOTDC001 until USN "D" and all the updates that originated on ROOTDC002 until USN "E".
  • Every other update that remains is replicated from ROOTDC001 to ROOTDC002.
  • Again, as you can see ROOTDC002 also sents its own latest up-to-dateness vector USN to ROOTDC001 so that anything that originated on ROOTDC002 and has replicated to ROOTDC001, is not replicated back to ROOTDC002. That is called propagation dampening, which prevents the continous replication between the same domain controllers for the same update.

Current and retired invocation IDs can also be seen for a certain naming context when using either REPADMIN and REPLMON.

When using REPADMIN (see output below as example):

  • REPADMIN /SHOWUTDVEC <* | FQDN DC LIST | FQDN DC> <NC>
    • When in addition using the /NOCACHE option, you will only see GUIDs with no names!

image

When using REPLMON (see output below as example):

  • Add ALL the DCs to the GUI as a monitored server
  • Goto the pull down menu VIEW and select OPTIONS
    • The first checked checkbox means: "Besides the current invocations IDs, also show the previous invocation IDs where changes can/could originate"
    • The second checked checkbox means: "Also show non-direct replication partners for a certain domain controller"
  • Red color: the naming context
  • Green color: Existing transitive replication partners (invocation IDs) and previous transitive/direct replication partners (invocation IDs)
  • Yellow color: direct replication partner within the same site
  • Blue color: direct replication partner within another site
  • Right-clicking an existing or a non-existing database instance will show the USN on the "Update Sequence Number" tab

image

Using both REPADMIN you will see your live DCs and possible a bunch of GUIDs and in REPLMON you will see something like "**DELETED SERVER". IMHO, REPLMON should NOT display "**DELETED SERVER", but it should display "Retired Database Instance" (or something similar) as that explains better what it in reality is!

Viewing those GUIDs in AD:

The objectGUID property of each object and the invocation ID of DCs within Active Directory is stored in the directory as an octet string. Depending on the tool used you will either see the string format or the octet format of a GUID.

For those command shown in the picture you see the DC-GUID and the Invocation ID in string format.

image

Now lets look at the GUIDs again using LDP and using ADSIEDIT

  • Using LDP
    • 1> invocationId: 3ad22a03-d9ca-4d8f953614b0c2632caf;
    • 1> objectGUID: 4622217c-a587-4c73ba450fdb359a840f;
  • Using ADSIEDIT
    • invocationId: 03 2A D2 3A CA D9 8F 4D 95 36 14 B0 C2 63 2C AF
    • objectGUID: 7C 21 22 46 87 A5 73 4C BA 45 0F DB 35 9A 84 0F

As you can see the yellow, green, blue and pink parts are exactly the same except for the orange and red parts. So how can these from the same DC if they are different?

The answer is easy, as long as you know it!πŸ˜‰ So, let’s look at how these are the same….. (to make more easy the changed all to uppercase characters) As an example I’m using the invocation ID shown above in color.

image

Joe Richards provides a function to convert the GUID here: "Converting octetstring GUID values to GUID strings using vbscript".

Microsoft provides a function to convert the GUID here: "How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory".

You can also use the script (GUIDConverter.hta) provided in the attachment, which was made by Graham Calladine, to convert the GUID in string format to a GUID in octet format. Download it and remove the TXT extension.

To query AD with a GUID in the query filter, you must use the GUID in octet format or you can use the string format when the tool used is able to convert it to an octet string. ADFIND from Joe Richards is such a tool that can do this. See below….

In the first example the GUID in octet format is used and in the second example the GUID in string format is used.

image

REMARK: In the picture above you will see a "strange" transformed filter. You can read more about that in the following article from Joe Richards: "Querying AD for GUIDs"

TIP: If you have 4 or more DCs within an AD site that replicate the same partition, by retrieving the objectGUID of each DC in the AD site and transforming it if needed into octet format you can determine how the replication topology ring is build within the AD site by putting the GUIDs in alphabetical order. Be aware that when the number of steps between each DC exceeds 3 additional paths are added to make sure that each DC is connected to each other DC within three or less steps.

Some FAQs:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

19 Responses to “(2006-12-09) DC-GUIDs And Invocation IDs”

  1. Do you really think anyone will read this article from beginning to endπŸ˜‰

    Nice work Jorge. Q: you say you should not remove those GUIDs or retired DC’s. Can you remove them at all, and if you do, what will go wrong?

  2. Jorge said

    As I know, you cannot remove those database IDs (Invocation IDs, GUIDs)
    The up-to-dateness vectors for a NC are stored in the “Repl-UpToDate-Vector” attribute of the NC head. That attribute is system owned (systemFlags=0x10hex | 16dec) and is therefore protected by the system.

  3. Ok, I admin I was teasing you a bitπŸ˜‰

    The wording in your FAQ suggests that you can remove it, that’s why.

  4. Jorge said

    No, it is a valid question. I know you know how it works, but in the newsgroups I have seen people ask..”what the hell are those GUIDs when I do showutdvec in repadmin and how can I remove them”. Because of that I wrote this post. I like it better to post information here and link to it each time, instead of writing the same story over and over again!πŸ˜‰.. You know, IT people are lazy and THAT’S WHY you should automate! ;-))

  5. Jorge said

    Another MVP friend of mine contacted me about the article above, and reminded me of some subtle changes he recommended to make within the article. As recommended by him I made those changes, being:
    * Viewing the GUIDs, their different notations and the relation between those notations
    * When the invocation ID changes (more specifically)

    Thank you “dude with the funny english accent”…πŸ˜‰

  6. Nice job, Jorge. Great work….. Congrats on being re-uped as MVP. Well deserved!

    Cheers, Rick

  7. Jorge,
    I have a question like, if any time USN rollback occurs in a domain can’t we manually modify (change GUIDs )
    to – replUpToDateVector
    add to – retireReplDSASignatures
    Change – invocationID

    and start replication ???

    Thanks
    JagadeeshT,

  8. Hi Jorge

    If it happen to observe a USN Roll back observed in a domain, instead of demoting and promoting the DC, can’t we add invocationID in retiredReplDSASignatures and start replication between DCs ?

    Jagadeesh

  9. Hi Jorge,

    It happen to see that one of our server was sending us 2095, 2103 Errors events. And server was not replicating to its partner for about 7 days.
    one of our admin run “dfsutil /purgemupcache” inorder to stop 1058 and 1030, before running that he started netlogon service and inbound, outbound replications.
    Surprise am able seen the replication working fine.
    previously DCs invocation ID and DC object GUID both are same now they are Different.
    Could you please comment on this situation.

    Thanks
    jagadeeshT
    (2k90625xxx1649)

  10. Jorge said

    USN RollBack is a “DC thing”, not a “Domain thing”. The only way to recover a DC from USN rollback is to FIRST demote the DC (normally or forced), and SECOND repromote it. Make to cleanup the AD metadata if you force demoted the DC!.
    More about USN rollbacks:
    http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

  11. Jorge said

    Because AD replication works, it DOES NOT mean you have solved USN rollback.

    USN Rollback may end up with inconsistent AD databases between DCs! For example, the contents of the AD database of a DC that suffered USN rollback may be different when compared to another DC, even if there is nothing more to replicate!

    For more info about USN rollback see:
    http://blogs.dirteam.com/blogs/jorge/archive/2006/03/08/597.aspx

  12. I’d learned a lot from your article~! I had a question. Will the invocation ID removed if I reformat and rebuild that particular DC which had plenty of “deleted server” entries/record?

  13. Jorge said

    by the deleting/removing/demoting the server (DC) that once owned that invocationID, you may not be able to translate it to a readable name. Instead you will get a GUID. The invocationID will never leave AD anymore because it is the way of AD keeping by WHERE some change was implemented.
    For the rest of the story, see above in the post

    Regards,
    Jorge

  14. Hi Jorge

    My Question is a old question. But little bit confusion in it.

    If we observe a USN Roll back in a DC, instead of demoting and promoting the DC, can’t we Delete invocationID in retiredReplDSASignatures and start replication between DCs ?

    Jagadeesh

  15. Jorge,

    retiredReplDSASignatures is a attribute owned by system, which is not editiable by the domain admin.

    Jagadeesh

  16. Jorge said

    like I said earlier… see the earlier comments about the invocationIDs

  17. zagadeesh said

    I just wanted to add one more point here –

    If we type repadmin /showmeta objectname
    then it will results the following
    – Total entries
    – Local USN
    – Originating DC
    – Originating USN
    – Originating Time/Date
    – Version
    – Attribute

    But if you open the same object in adsiedit.msc and check for “msDS-ReplAttributeMetaData” we can observe same amount number of attributes.

    thing here is this multivalued string which will be like following :-

    objecttype (viz ou, user)
    version#
    date and time
    INVOCATION ID
    usn #
    usn #
    DN

    So every attribute will tightly bundled with InvocationID which will be checked if any USN # change to previous.

    -jagadeesh

  18. Jorge,

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

    – 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.

    when I tried to do so Invocation ID was not modifying ?

    Technet is wrong or is there any other considerations are there ?

    – Jagadeesh

  19. Ernest said

    Great Post

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: