I was asked the other day what the FSMO roles were. I remember them being apart of one of the Windows 2k3 MCSE exams but couldn’t remember for the life of me what they were. It was certainly embarrassing and as soon as I was at a workstation I looked up what they were. I thought that I would share them all with you just in case you forgot as well.
When there is only one Domain Controller in an environment that DC holds obviously all the roles. However in larger environments it is a best to distribute them amongst your other Domain Controllers in the forest.
In an AD forest the Schema Master is where all the Schema changes and updates happen. Once the changes to the Schema are made it is replicated to the other Domain controllers. Like most FSMO roles, there can only be one Schema Master in the whole forest.
Domain Naming Master
This Server/Role holds the rights to add and delete domains from the forest. It is also the server that controls federation and links to other directory environments. Like the Schema role, there can only be one Domain Naming Master.
The Infrastructure Master role is a little more complicated. Within an AD structure all the different elements are referenced by the GUID, SID and the DN for the object. Within the forest and the federated relationships the Infrastructure Master is responsible for updating the GUID/SID and DN for the other Domain Controllers.
Relative ID (RID) Master
The GUID and SID’s that we referenced earlier when they are created they are created on the various domain controllers. So whenever someone creates a user account, an OU or a Security Group it creates the GUID and SID as well as the Relative ID. A RID is created for each GUID and SID. Each DC is allotted a certain amount of RID’s when it runs out of RID’s it must ask the RID master for more. There can only be one RID master.
In NT4 days (1997-2000) there were two types of domain controllers Primary DC’s and Backup DC’s. A PDC emulator is only required only in a mixed environment.
- Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
- Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.
- Account lockout is processed on the PDC emulator.
- Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator’s SYSVOL share, unless configured not to do so by the administrator.
- The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.* (Borrowed from Daniel Petri)
There can be a PDC emulator in each Domain in the Forest and the only role that can be held by multiple servers in a forest.
and that’s the FSMO roles.. Next time I’m asked hopefully I’ll remember!