In this part of our Active Directory journey we will talk about the operations master roles (FSMO) and Forest and domain functional levels. Before we get into the actions let’s discuss about FSMO, what they are, how many we have and what was the issue with Multi-master model in the past.
Multi-master vs Single-Master model
Microsoft, in attempting to create a multi-master model for the AD database, one where every copy of the database was exactly the same, and there was no single master where everyone pulled their content from, realized that a small subset of the activities of AD could not be made multi-master. Some of these things worked best, or worked at all, when a single computer was responsible for the execution of that task.
In Multi-master model changes can occur at any dc which can lead to conflicts and issues once the data is replicated to the rest of the dcs. In multi-master model the last writer wins which means that changes will be discarded in all other DCs.
To prevent those conflicts Microsoft introduced Single-Master model where only one DC in the forest is allowed to process updates. In a forest, we have 5 FSMO roles that are assigned to one or more domain controllers. These 5 FSMO roles define a set of activities that have to occur on a specific machine. One domain controller can host all of them or we can separate them across multiple DCs. It’s easier to keep track of FSMO roles if you host them on fewer computers. Those are:
- Schema Master
- Domain Naming Master
- RID (Relative Identifier)
- PDC Emulator
Schema Master and Domain Naming Master are Forest Wide Roles, while RID, PDC and Infrastructure are domain wide roles.
Anytime you do any update to the Active Directory schema, not necessarily changing content in the database but changing the structure of the database itself. Updates like the adprep command, Microsoft Exchange’s update, any other applications that are going to modify the Active Directory schema, those changes have to happen on the domain controller server that has been configured as the schema master. There’s only one per forest, and generally that schema master is placed on the forest root, PDC. Most important thing to note here is that in order to do any changes to the schema you have to have a schema master up and operational.
DOMAIN NAMING MASTER
This role is what’s responsible for adding and removing domains and application partitions from the Active Directory forest, and has to be online any time you’re doing any of those adds or removes to domains or app partitions. As with the schema master, the domain naming master is generally placed on that forest root PDC.
PDC (Primary Domain Controller) Emulator
The PDC emulator handles password changes, so if you’re doing computer user accounts on DCs it handles the password changes. It’s consulted by your replica of the main controllers when you have surface authorization requests with mismatched passwords. It is the default target DC any time you’re doing any group policy updates. It is also the default target DC when you have any legacy applications that need to perform writable operations, and the PDC emulator tends to also be the timekeeper for the domain and forest. Your PDC emulator, because of, obviously, these things, needs be online and accessible at all times. And so you generally you can’t operate without having a PDC emulator up and running. It is important to note that the PDC is the most important role and should be placed on your best hardware in a reliable hub site alongside other domain controllers that can handle your everyday user authentication traffic when you’re in a very large organization where the emulator is doing a lot of tasks for a very large number of users and computers.
RID (Relative Identifier)
Its job is to create what are called relative IDs for the different objects that require permissions or whatnot to be associated with them. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain. The RID master’s gotta be online so that any newly promoted DCs can attain a local RID pool. Generally the RIDs are distributed by the individual DCs, and only when they run out of RIDs in their pool do they request another set of them from the RID master. And it generally is also placed on the forest for PDC. Every domain has a RID Master: a domain controller that hands each DC a pool of 500 RIDs at a time. Once issued, RIDs are never reused. A domain contains a single RID pool which generates roughly one billion SIDs.
What is RID?
Relative Identifiers (RID) are the incremental portion of a domain Security Identifier (SID). A SID represents a unique trustee, also known as a “security principal” – typically users, groups, and computers – that Windows uses for access control.
Its job is to update references in the local domain from any objects that exist in other domains, so these cross-domain references. You’ve seen this if you have a domain where your domain trusts another domain, either inside of a forest or outside through some forest trust. If you have that situation where instead of seeing a username you’ve seen a long list of numbers in the permissions dialog box when you’re trying to assign permissions, it’s the job of the infrastructure master to translate that SID into a friendly name so you actually know what you’re looking at. It’s also the job of the infrastructure master to manage any phantoms or tombstones out of the global catalog. If all DCs are Global Catalogs this role can be placed on any DC. If every domain controller in a domain that is located in a multidomain forest does not host the global catalog, the infrastructure master must be placed on a domain controller that does not host the global catalog. If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold.
TRANSFER VS SEIZE FSMO ROLES
It is very important to know that transfer and seizure are two very different activities. Transfer is a graceful move of the role from one server to the other, whereas the seizure is a non-graceful move. The only time you would go through accomplishing a seizure is if for some reason your DC is completely dead, completely offline and unable to be brought back online. Seizure is something you really never want to have to do but it is possible so that you can essentially recreate the role onto a new surviving machine once you know that the previous host of that role is no longer available.
Let’s see where we can locate those FSMO roles. First we will use GUI and then we will use powershell for the same.
Open you ADUC and right-click on you domain and select OperationsMasters…
- PDC, Infrastructure and RID are located here.
- Change button –> You will notice that RID, PDC and Infrastructure are located on DC01 and that the target DC is DC01 as well. When you are transfering roles be sure that you are on the taget domain controller and not on the source.
What you can do now is to right-click on your domain and select Change domain controller
We can see our current and available DCs. Select your target DC
Now if you right-click on your domain and if you select Operations Masters you will be able to transfer FSMO roles to that server.
DOMAIN NAMING MASTER ROLE is located in Domains and Trusts.
Process is the same, change the DC and transfer to target dc.
To access Schema Master we need to open the schema master’s console, which is not one that’s directly available right out of the box. This is done on purpose because Microsoft wants to make it a little bit difficult for you to even find the schema master console, because of all the possibility for you clicking around in there and performing something horrible that corrupts your Active Directory database. In order to make available the schema master role we have to do a couple of things first, not the least of which is to bring up an elevatedcmd or powershell and register the DLL that’s associated with that Microsoft management console. Run regsvr32 schmmgmt.dll
Now we have to run mmc and we will able to see AD Schema
Add it and right-click on it –> Operations Master
To transfer it select Change. One more time, you have to be on the target DC to be able to transfer the roles
POWERSHELL (TRANSFER FSMO ROLES)
You will notice that there are a lot of steps involved to accomplish fsmo transfer to a different DC. Let’s see how we can accomplish this with few commands. Note that there is not only one way to accomplish this. Open powershell as admin and type in netdom query fsmo or if you like powershell way Get-ADForest | select schemamaster,domainnamingmaster –> For FOREST WIDE ROLES and Get-ADDomain | select ridmaster,pdcemulator,infrastructuremaster –> for Domain wide roles
Once we know that we can transfer roles by running Move-ADDirectoryServerOperationMasterRole -Identity <target dc> -OperationMasterRole 0,1,2,3,4
You will notice that I used numbers insted of typing the names of the operations master roles. It is much easier
PDCEmulator –> 0
RIDMaster –> 1
InfrastructureMaster –> 2
SchemaMaster –> 3
DomainNamingMaster –> 4
If you need to seize all roles you will need to use -force parameter. If you need to seize only specific role specify the nr that represent that role.
DOMAIN / FOREST FUNCTIONAL LEVEL
What you need to know about DFL and FFL is that they represent advanced features that are available with the newest software that can be used in the domain. Usually when you administer large AD environment you will notice that you have different Windows OS versions on your DCs. If you have DCs that are 2008 R2, 2012 and you install 2016 you will not be able to use latest advanced features that comes with 2016 until you upgrade all you DC’s to 2016 and raise functional level. AD features are not backward-compatible with AD domain controllers on earlier versions of Windows Server so if you are running 2008 R2 and you install 2016 you will be limited to those features that comes with 2008 R2. Functional levels can be used to decide which DCs are allowed to run in our environment. For example if we raise functional level to 2016 we will not be able to install 2012 R2 DC in our domain. You cannot set the domain functional level to a value that is lower than the forest functional level, but you can set it to a value that is equal to or higher than the forest functional level.
To check the DFL / FFL you can use GUI or Powershell.
GUI –> Right-click on your domain and select properties.
RAISE DOMAIN AND FOREST FUNCTIONAL LEVEL
In ADUC right-click on the domain and select Raise DFL
I am running on 2016 so I am not able to raise it more than that but you come here to raise domain functional level.
To raise forest functional level you need to open domains and trusts
Set-ADForestMode -Identity <your domain here> -ForestMode <forest mode here>
Set-ADDomainMode -Identity <your domain here> -DomainMode <forest mode here>
REVERT BACK / DOWNGRADE TO PREVIOUS MODE
There is no GUI to perform this downgrade. You should carefully evaluate this decision and be aware of possible implications the change can have on other applications. Key to point is that we cannot go lower then 2008 and we need to downgrade forest functional level first. Order is important.
Command is the same for downgrade
Set-ADForestMode -Identity <your domain here> -ForestMode <forest mode here>
That’s it. I hope this has been informative for you. Our journey will continue with Active Directory Sites and Services.