AD DC-GUIDs And Invocation IDs

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:
  • Wanna know why ‘VALID’ is written in uppercase?
    • –> Read: "Backup And Restore Of Active Directory"
• 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

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

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

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

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

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

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!

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

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.

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

• Using LDP
  • 1> invocationId: 3ad22a03-d9ca-4d8f–9536–14b0c2632caf;
  • 1> objectGUID: 4622217c-a587-4c73–ba45–0fdb359a840f;
• 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.

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.

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:

• Q: Is it important to remove those GUIDS?
• A: No, that information should be there!
• Q: Should you worry about this?
• A: Hell NO!
• Q: Where can I get more information about detailed Active Directory replication
• A1: How the Active Directory Replication Model Works
• A2: How Active Directory Replication Topology Works

–