Every forest must have the following roles:

• Schema master ( managed through Active directory schema MMC)
• Domain naming master ( managed through Active directory Domain and Trust MMC )

These roles must be unique in the forest. This means that throughout the entire forest there can be only one schema master and one domain naming master.

The schema master domain controller controls all updates and modifications to the schema. To update the schema of a forest, you must have access to the schema master.

Its absence is not apparent to users or admins unless a schema change is attempted. Generally, the schema master should be transferred to another server only when you are certain the original server will be down permanently.

By default, the Schema master snap-in is not in the MMC selection list, to enable it type:

regsvr32 schmmgmt.dll

The domain controller holding the domain naming master role controls the addition or removal of domains or DC in the forest.  If the DC performing this role goes offline, you should wait until it comes back online before attempting to add or remove a domain or DC.

If you decide to install this role on another DC, the original domain naming master must not be put back into service unless you uninstall AD.

Note

• Any domain controller running Windows Server 2003 can hold the role of the domain naming master. A domain controller running Windows 2000 Server that holds the role of domain naming master must also be enabled as a global catalog server.
• Ideally, the Domain naming master should also be a global catalog server. Domain naming master and schema master, can be, but need not be on the same server.

Every domain in the forest must have the following roles (can be transferred from “Active Directory Users and Computers”:

• Relative ID (RID) master
• Primary domain controller (PDC) emulator master
• Infrastructure master (better not to be on the same DC which is the also the GC)

These roles must be unique in each domain. This means that each domain in the forest can have only one RID master, PDC emulator master, and infrastructure master.

The RID master allocates sequences of relative IDs (RIDs) to each of the various domain controllers in its domain. At any time, there can be only one domain controller acting as the RID master in each domain in the forest.

Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID (SID). The SID consists of a domain SID, which is the same for all SIDs created in the same domain, and a RID, which is unique for each SID created in the domain.

Because the RID master rolls out RIDs to DCs in blocks of 500, temporary downtime might not be noticed. However, if a DC has exhausted its pool of RIDs, and the RID master is not available, net objects can’t be created.

NOTE: To move an object between domains (using Movetree.exe), you must initiate the move on the domain controller acting as the RID master of the domain that currently contains the object.
Better to be on the same server with PDC emulator master role, because the PDC emulator uses the RID master’s services frequently.

In the event of an RID master failure, moving this role to another server should be considered only if  the original RID master is down permanently.

The PDC emulator master processes password changes from client computers and replicates these updates to all domain controllers throughout the domain. At any time, there can be only one domain controller acting as the PDC emulator master in each domain.

The PDC emulator processes password changes for older Windows clients (Windows 9x and NT) and is used during logon authentication.

NOTE: It is the most heavily used of the FSMO roles and should be placed on a suitable DC, which should not be a GC server because GC server is also used heavily. Better to be on the same server with RID master role, because the PDC emulator uses the RID master’s services frequently.
If the PDC emulator role fails, you might move the role to another server immediately and move back to original server when it returns to service.

The PDC emulator role is used in the following ways:

• To provide consistent password experience for users across sites (can be turned off with AvoidPdcOnWan registry parameter) – The PDC emulator is used as a reference DC to double-check incorrect passwords and it also receives new password changes. When the PDC is reachable, users can use a new password immediately and consistently across the environment. For more information about AvoidPdcOnWan see, New Password Change and Conflict Resolution Functionality in Windows (http://go.microsoft.com/fwlink/?LinkId=202451)
• As a preferred point of administration for services (examples are Group Policy and Distributed File System, DFS) – For more information about DFS see, DFS Management (http://go.microsoft.com/fwlink/?LinkId=202456). For more information about DCs and Group Policy see, Specifying a Domain Controller for Editing Group Policy (http://go.microsoft.com/fwlink/?LinkId=202457).
• As a point of contact for applications hard-coded to the PDC (often written for Windows NT 4.0 and older domains) – The legacy API often used for this is NetGetDcName. It is strongly suggested to change applications to use the new API to locate DCs. DsGetDcName by default does not target the PDC, and has more options that allows you to pick the type of DC needed to perform the operation. For more information about locating DCs from applications see, DSGetDcName Function (http://go.microsoft.com/fwlink/?LinkId=202455).
• As a default time server for all other DCs in the domain – The time server configuration of a PDC requires manual consideration and should be reviewed when you change the owner of the PDC role.

The domain controller configured with the PDC emulator role supports two authentication protocols:

• The Kerberos V5 protocol: anti the replay attack, put a time-stamp on the authentication request packets, basically within a period of time ( 5 minutes).  So, if someone capture the authentication request and replay it afterward,
• The NTLM protocol

Note
For instructions on how to configure the PDC emulator to synchronize with an external time source, see Synchronize the Time Server for the Domain Controller with an External Source (http://go.microsoft.com/fwlink/?LinkId=122513).

The infrastructure master is responsible for updating references from objects in its domain to objects in other domains. The infrastructure master compares its data with that of a global catalog. Global catalogs receive regular updates for objects in all domains through replication, so the global catalog data will always be up to date. If the infrastructure master finds data that is out of date, it requests the updated data from a global catalog. The infrastructure master then replicates that updated data to the other domain controllers in the domain.

This role is most needed when many objects have been moved or renamed.

Important

• Unless there is only one domain controller in the domain, the infrastructure master role should not be assigned to the domain controller that is hosting the global catalog(GC). If the infrastructure master and global catalog are on the same domain controller, the infrastructure master will not function.
  The infrastructure master will never find data that is out of date, so it will never replicate any changes to the other domain controllers in the domain. In the case where all of the domain controllers in a domain are also hosting the global catalog, all of the domain controllers will have the current data and it does not matter which domain controller holds the infrastructure master role.
  However, the Infrastructure Master role should be in the same site as the GC server, because there’s frequent communication between these two roles.

The infrastructure master is also responsible for updating the group-to-user references whenever the members of groups are renamed or changed. When you rename or move a member of a group (and that member resides in a different domain from the group), the group may temporarily appear not to contain that member. The infrastructure master of the group’s domain is responsible for updating the group so it knows the new name or location of the member. This prevents the loss of group memberships associated with a user account when the user account is renamed or moved. The infrastructure master distributes the update via multi-master replication.

There is no compromise to security during the time between the member rename and the group update. Only an administrator looking at that particular group membership would notice the temporary inconsistency.

Operations master best practices

Common rules for operations masters:

1. Unless your domain is very small, transfer operations master roles from the first DC installed in the forest to other DCs because some FSMO roles can be quite resource intensive.
2. Place the servers performing these roles where network availability is high.
3. Designate an alternate DC for all roles. Document your plan to make sure alternate DCs aren’t burdened with other services that could impede their performance.

Reasons to transfer roles to other server:

• Affect replication speed
• Recover from a server failure faster
• Some roles must be functioning almost continuously for proper domain operation,  but other roles can be offline for a while with little disturbance to the network.

Seizing Operations master Roles

An operations master role is seized when the current role holder is no longer online.

Seizing should never be done when the current role holder is accessible and should usually be done only when it’s unlikely the original server can be restored to service.

• If a DC is scheduled to be decommissioned, you should transfer the role while the DC is still online.
• If the operations master DC becomes inaccessible because of network failure or a temporary hardware failure, you should wait until this server is back online rather than seize the operations master role.

Exception of the conditions above is : PDC emulator role, which can affect user logons, or the RID master, which might be needed to create AD objects. If either role holder is going to be offline for an extended period, seizing the role and then transferring it to the original DC when it’s back online.