Isn’t the title of this blog post a bit strange? RID Masters and InfrastructureUpdate Objects? Shouldn’t it be Infrastructure Update Masters and InfrastructureUpdate Objects? – It could have been if this blog post was written in the year of 2000 – but it’s 2026 now and things change.
But let us go back to Windows 2000 and have a sort summary of what the IM does
A very detailed explanation (possibly the most detailed that exist) of what the IM or none-GC DCs (If Recycle-Bin is enabled) are responsible for is already available in if you start reading at “Let’s have a look at “Cross Naming Context (NC) references in NTDS.dit” in How the Active Directory–Data Store Really Works (Inside NTDS.dit)–Part 4 – Christoffer Andersson you will find those details.
Summary Windows 2000 – Windows Server 2008
The IM only have something to do in a multiple-domain forest, and only in domains that have at least one none-GC DC, if there is only one none-GC DC in a such forest – it has to hold the IM.
Summary Windows Server 2008 R2 – Windows Server vNext
Exactly the same as up until Windows Server 2008, after that still the same unless if the Recycle-Bin is enabled – If Recycle-Bin is enabled any none-GC DC will handle phantoms (Cross-DB/Domain reference integrity) – hence the IM as a FSMO has no work to do anymore and as each none-GC DC resolves the tasks them self, there is no need to create “carrier” objects in form of InfrastructureUpdates.
The RID Master
So in my session I mention that if the Recycle-Bin is enabled in the forest, the RID Master is the only FSMO that creates InfrastructureUpdate objects now days, but only certain conditions only – the most obvious role for the RID Master is to allocated and handle out RID pools to domain controllers within the domain – but let’s look at the documented description of the RID Master
So the the RID Master is responsible for cross-domain move (XDOMMOVE) aka interdomain moves – this means that a such move only can originate from a domains RID master, this is not a blog post about XDOMMOVE it self- trust me when I say that I’ve tried to write a blog article series about that very subject for several years, it’s one of the most complex working of Active Directory if you ask me – some day I might be able to finish it.
This is how an XDOMMOVE is performed in a multi-domain forest with both GCs and DCs (none-GCs)
1 – The user XDOM resides in D1
2- The user XDOM is moved from D1 (CN=XDOM,CN=Users,DC=D1) to D2 (CN=XDOM,CN=Users,DC=D2) – the move can only be initiated from the RID Master in D1 (D1-DC1)
2- RID Master creates an InfrastructureUpdate object with the attribute proxiedObjectName set to the objects new DN (CN=XDOM,CN=Users,DC=D2) and the binary portion to indicate it’s a moved object and 0 because it’s the first name the object is XDOMMOVE’ed
2 – The DC in the destination domain will create the object and in addition also set the attribute proxiedObjectName to DC=D1 to indicate the object was moved and last time it moved to instance the object it came from the domain D1
2+ – The infrastructureUpdate object replicates out to other DCs/GCs in D1, they will update the name of the object from CN=XDOM,CN=Users,DC=D1 to CN=XDOM,CN=Users,DC=D2 and phantomize the object (record in the database) to a phantom – the record in the database will keep it’s DNT
3 – The object CN=XDOM,CN=Users,DC=D2 now replicates out authoritatively in the forest belonging to D2, once this reaches GCs in D1, the phantomized object representing the moved object to D2 is now promoted back to an object and partial attributes are added – the row in the database will keep it’s DNT
This explain the usage of InfrastructureUpdate objects used by the RID FSMO Master for XDOMMOVE.
Moving the RID FSMO Master must also move the InfrastructureUpdate objects – but way?
So having the requirement of only being able to move objects off from the RID FSMO in the source domain during XDOMMOVE prevents several DCs to move the same object away to different destinations – cleaning that up would be very difficult once replicated out in the forest.
But if you move the RID FSMO from one DC to another DC (From D1-DC1 in Site to D1-DC2 in site2) as in the illustration move, this happens instant using the drsuapi RPC Interface and the GetNCChanges function when called with the extended operation to move the FSMO and the role is transferred instantly without any replication latency.
However we are now again in a dangerous state as the infrastructureUpdate objects that phantomize already XDOMMOVE’d objects takes the normal replication path and are there for subject to replication latency, the RID FSMO could potentially move, already moved objects again to other destinations (domains) – well thankfully this is engineered in such a way that if you move the RID FSMO – during the move all infrastructureUpdate objects having a ‘proxiedObjectName’ is moved within the same operation.
The condition of ‘proxiedObjectName’ is to not move InfrastructureUpdate objects eventually produced by the IM FSMO.
The 3rd undocumented producer of one InfrastructureUpdate object – the fix behind KB810089
So we have to go back in time to understand this one, or at least Pre-Windows 2000 Server SP4 or to be more specific KB810089
My understanding is that this was fixed up in several steps and places
- Patched DC – first DC in new domain with a name that has previously existed in the enterprise (forest)
- Patched ntdsutil.exe to fix up mangled nCName referances
- Patched ntds.dll/ntdsai.dll – the core ds to prevent this from happen at all.
Fix (1.) is implemented in the install/boot code that is called by DCPROMO when you create a new domain within an existing forest, and here the ds devs made a smart move by creating and deleting an InfrastructureUpdate object in CN=LostAndFoundConfig,DC=X, named CN=CRUpdate,CN=LostAndFoundConfig,DC=X with the ‘dNReferenceUpdate’ attribute set to point to the newly created domain’s crossRef objects (via the IDL_DRSAddEntry API using the Directory Replication Service (DRS) Remote Protocol) value of nCName.
Since the InfrastructureUpdate is created/deleted in the same transaction and moved to the Deleted Objects container, it’s guaranteed to replicate in before any corssRef objects in the Partitions container and would reserve the name with a phantom that has name, guid and sid of the newly created domain at replicas in the enterprise (forest) or eventually improve an existing name to resolve a name conflict.
Here is a view of the DIT just pre-restart after promotion of the first DC in a new domain:
Here is the LDP.exe view post-restart after the promotion of the first DC in a new domain:
This is an illustration that might not be correct, but should give an idea:
It’s been very hard to get the correct picture of this, might some one who was part of designing KB810089 can reach out and inform us how it’s really working? How ever I’m sure this is the 3rd case that make use of InfrastructureUpdate objects at least.
This concludes this blog post and the is the final one in the series of blog posts covering the topics from my HiP 2026 Europe session “Inside Active Directory: Misconceptions, Myths and Bugs” – It’s been fun!
Note: When I did spend way to much time on this last 3:rd case I come across another bug in the DS, that isn’t accent – in fact it hasn’t been fixed yet, as I just reported it to Microsoft.