Transfer, Seize and Placement of FSMO role ( Third of three post series)

Hi Friends

So, now we are on third post of FSMO series. In first two post we had discussed what FSMO is and their details. If you have not checked them yet you can read them here:

https://vinitpandey.wordpress.com/2015/10/21/fsmo-role-first-of-three-blog-series/

https://vinitpandey.wordpress.com/2015/10/21/fsmo-roles-in-detail-second-of-three-blog-series/

In this final blog we will discuss transfer, seize and placement of FSMO roles. So, lets start.

Transfer of FSMO roles

As discussed, first DC in forest holds all five roles and first DC in domain holds all three domain wide roles. These roles can be transferred to other DC for the following:

1. Load Balancing
2. In event when original operation master need to be offline ( for maintenance, troubleshooting etc.)

You can transfer FSMO role via GUI and command prompt.

GUI

In previous post we had discussed how to view operation master role. To transfer them first you need to connect to DC on which you need to transfer role. Then you can change it by clicking on “change” button.

To transfer FSMO roles by command prompt steps are as under:

• Open a command prompt
• Enter in ntdsutil
• At the ntdsutil command prompt enter in roles
• At the fsmo maintenance prompt enter in connection
• At the server connections prompt enter in connect to <domaincontrollername>
• At the server connections prompt enter in quit
• At the fsmo maintenance prompt enter in transfer <FSMO role name>
• Quit from the console

Seizing FSMO roles

Transfer of role is only possible if current operation master is online. In event of failure of FSMO master you have to seize operation master role. Before you seize operation master role you have to make sure that DC where you will transfer role is up-to-date. If not, you need to wait or run repadmin/syncall commands.  Seizing can be done only via command line. Steps are as under:

• Open a command prompt
• Enter in ntdsutil
• At the ntdsutil command prompt enter in roles
• At the fsmo maintenance prompt enter in connection
• At the server connections prompt enter in connect to <domaincontrollername>
• At the server connections prompt enter in quit
• At the fsmo maintenance prompt enter in Seize <FSMO role name>
• Quit from the console

Note : Seizing a role is a drastic step and you should perform only when the previous role owner will never be available again. Don’t seize an operations master role when you can transfer it gracefully using the normal transfer procedure.

Placement of FSMO role

Ok, so finally lets discuss what are best practices for placing FSMO roles.

1. You should place the forestwide roles, schema master and domain naming master, on the same domain controller. There is very little overhead associated with these roles, so placement on the same server adds very little load overall. However, you must safeguard this server because these are critical roles in the forest. In addition, the server acting as the domain naming master should also be a global catalog server.
2. You should place the RID master and PDC emulator roles on the same domain controller. The reason for this is that the PDC emulator uses more RIDs than most other DCs. If the RID master and PDC emulator roles aren’t on the same DC, the DCs on which they are placed should be in the same Active Directory site, and they should have a reliable connection between them.
3. Don’t have Infrastructure master on Global Catalog Server.

Why not Infrastructure and Global Catalog be on same server ?

This is the question asked in nearly all my trainings. So, here is the answer.

The infrastructure master is responsible for updating cross domain group memberships. So, if a user is member of a group which is in another domain, once username is changed you can see name got updated in “member” tab of the group . To perform this infrastructure master periodically scans its database for group members from other domains. For each member from a foreign domain that the infrastructure master finds, it compares the name and the security identifier (SID) of the member against a global catalog. If the name or the SID does not match, the local reference is updated with the values in the global catalog. Because a global catalog maintains a partial attribute set of every object from every domain in the forest, the requirement to maintain any cross-domain references is eliminated. Therefore, if the infrastructure master is running on a global catalog server, it never finds any cross-domain references in its local database. Consequently, the infrastructure master is not able to determine which cross-domain references have changed and any changes (like in example above where username had changed) won’t replicate . For this reason, the infrastructure master should not run on a global catalog server in a forest that contains multiple domains.

The following exceptions apply:

• If every domain controller in a domain is a global catalog server, no cross-domain references exist which solves replication issues.
• If a given domain in a multidomain forest contains only one domain controller, the domain controller is the infrastructure master itself, or a global catalog. Therefore, the issue is not relevant.

So, here we finish this three post series. This was really big but important series.

I will see you guys soon with some other technical stuff. Till then take good care of yourself. Bye.