Active Directory: Operations Master Roles (contd.)

This is a continuation to my previous post on AD FSMO roles. I had to wrap that up in a hurry as I was distracted by other things. 

Identifying the FSMO role holders

Easiest would be to use netdom or dcdiag: 

You could also use ntdsutil (if you can remember the long commands!)

The overall idea with all these commands is the same. You connect to a specified server or any sever in a specified domain. Then you query that server for the FSMO roles it knows of. 

If PowerShell is your friend, then the Get-ADDomain and Get-ADForest cmdlets are your friends. The output of these cmdlets show you the current FSMO role holders:

Finally, if a GUI is your weapon of choice, there’s three different places you will have to look:

  1. In AD Users and Computers, right click the domain and select “Operations Masters”. This will show the RID Master, PDC, and Infrastructure Master – the three domain specific FSMOs.
  2. In AD Domains and Trusts, right click on AD Domains and Trusts and select “Operations Masters”. This will show the Domain Naming Master. 
  3. Open a command prompt or run window, type regsvr32 schmmgmt.dll, then open MMC, add a snap-in called AD Schema and open it, and then right click on AD Schema and select “Operations Masters”. This will show the Schema Master. 

Transferring FSMO role holders

With a GUI transferring role holders is easy. In each of the screens above when you view the role holder there’s also an option to change it. 

To transfer/ seize a role with ntdsutil you first connect to the DC that will now hold the role, and issue a transfer/ seize command. As the names imply transfer is a “clean” way of moving the role, while seize is a seizing of the role. You seize roles when the DC that currently has the role is down/ unreachable and you can’t wait for a graceful transfer. For example: 

When you attempt a seize, ntdsutil attempts a transfer first and if that succeeds then a transfer is done instead of a seize.  

Things are much easier with PowerShell. One cmdlet, and you are done:

A neat thing about this cmdlet is that you don’t have to necessarily specify the role name. Each role has a number associated with it so you could simply specify the number instead of the role name as a parameter. 

  • PDCEmulator is 0
  • RIDMaster is 1
  • InfrastructureMaster is 2
  • SchemaMaster is 3
  • DomainNamingMaster is 4

This is quite convenient when you want to specify multiple roles to be moved. Much easier typing -OperationMasterRole 1,2,3 than -OperationMasterRole RIDMaster,InfrastructureMaster,SchemaMaster. 

I prefer ntdsutil over PowerShell as it gives confirmation and so I know the transfer/ seize has succeeded. 

The fsMORoleOwner attribute

The commands above show how to view and/ or transfer FSMO roles. But where exactly is the information on various roles stored in AD? Many places actually …

There is an attribute called fsMORoleOwner. Different locations have this attribute present, and the value of this attribute at these locations indicate which DC holds a particular role. (The attribute can be viewed using ADSI Edit or PowerShell).

  • In the domain partition, the DC=domainName container has this attribute. The value there points to the DC with the PDC Emulator role. 
  • In the domain partition, the CN=Infrastructure,DC=domainName container has this attribute. The value there points to the DC with the Infrastructure Master role. 
  • In the domain partition, the CN=RID Manager$,CN=System,DC=domainName container has this attribute. The value there points to the DC with the RID Master role.
  • In the configuration partition, the CN=Schema,CN=Configuration,DC=forestRootDomain container has this attribute. The value there points to the DC with the Schema Master role.
  • Lastly, in the configuration partition, the CN=Partitions,CN=Configuration,DC=forestRootDomain container has this attribute. The value there points to the DC with the Domain Naming Master role.

What this means is that you can change this attribute and effectively transfer the FSMO role from one DC to another. For instance: 

That said I wouldn’t generally transfer/ seize roles this way. For one, I am not sure whether ntdsutil and/ or PowerShell does anything else behind the scenes (maybe replicate the change with priority?). For another, occasionally I have got errors like “The role owner attribute could not be read” when trying to change the attribute. These errors seem to be related to corrupt DC entries in FSMO roles, so don’t push your luck. (Or maybe I wasn’t connecting to the DC currently holding that role – not sure. You have to be connected to the DC holding the role to change this attribute). 

Another thing to keep in mind is that after you transfer/ seize a role the change has to update through out the domain. Once you think of it in terms of the attributes above that makes sense. When a change is made the attribute is updated and that update as to replicate throughout the domain for other DCs to know.

Lastly, I hadn’t realized this before, but FSMO roles apply to each application partition too. They are not only for the domain partitions (as I had previously thought). To transfer/ seize FSMO roles of application partitions one must update the attribute directly as above. 

That’s all for now!

Update: When a DC holding one of the FSMO roles comes online after a reboot it will do an initial sync with its partners before advertising itself as a DC. During this initial sync it will check the fsMORoleOwner attribute to verify that it is still the FSMO role holder. If it still it, it will start advertising its services; if not, it will stop advertising that role. More here …