What are the considerations for the FSMO placement in Active Directory?
Windows 2000/2003 Active Directory domains utilize a Single Operation Master method called FSMO (Flexible Single Master Operation), as described in Understanding FSMO Roles in Active Directory.
In most cases an administrator can keep the FSMO role holders (all 5 of them) in the same spot (or actually, on the same DC) as has been configured by the Active Directory installation process. However, there are scenarios where an administrator would want to move one or more of the FSMO roles from the default holder DC to a different DC.
Windows Server 2003 Active Directory is a bit different than the Windows 2000 version when dealing with FSMO placement. In this article I will only deal with Windows Server 2003 Active Directory, but you should bear in mind that most considerations are also true when planning Windows 2000 AD FSMO roles.
In a single domain forest, leave all of the FSMO roles on the first domain controller in the forest.
You should also configure all the domain controller as a Global Catalog servers. This will NOT place additional stress on the DCs, while allowing GC-related applications (such as Exchange Server) to easily perform GC queries.
In a multiple domain forest, use the following guidelines:
In the forest root domain:
If all domain controllers are also global catalog servers, leave all of the FSMO roles on the first DC in the forest.
If all domain controllers are not also global catalog servers, move all of the FSMO roles to a DC that is not a global catalog server.
In each child domain, leave the PDC emulator, RID master, and Infrastructure master roles on the first DC in the domain, and ensure that this DC is never designated as a global catalog server (unless the child domain only contains one DC, then you have no choice but to leave it in place).
Configure a standby operations master – For each server that holds one or more operations master roles, make another DC in the same domain available as a standby operations master. Making a DC as a standby operation master involves the following actions:
The standby operations master should not be a global catalog server except in a single domain environment, where all domain controllers are also global catalog servers.
The standby operations master should have a manually created replication connection to the domain controller that it is the standby operations master for, and it should be in the same site.
Configure the RID master as a direct replication partner with the standby or backup RID master. This configuration reduces the risk of losing data when you seize the role because it minimizes replication latency.
To create a connection object on the current operations master:
In Active Directory Sites and Services snap-in, in the console tree in the left pane, expand the Sites folder to see the list of available sites.
Expand the site name in which the current role holder is located to display the Servers folder.
Expand the Servers folder to see a list of the servers in that site.
Expand the name of the server that is currently hosting the operations master role to display NTDS Settings.
Right-click NTDS Settings, click New, and then click Connection.
In the Find Domain Controllers dialog box, select the name of the standby operations master then click OK.
In the New Object-Connection dialog box, enter an appropriate name for the connection object or accept the default name and click OK.
To create a connection object on the standby operations master perform the same procedure as above, and point the connection to the current FSMO role holder.
Note regarding Windows 2000 Active Directory domains: If the forest is set to a functional level of Windows 2000 native, you must locate the domain naming master on a server that hosts the global catalog. If the forest is set to a functional level of Windows Server 2003, it is not necessary for the domain naming master to be on a global catalog server.
Most FSMO roles require that the domain controller that holds the roles be:
Highly available server – FSMO functions require that the FSMO role holder is highly available at all times. A highly available DC is one that uses computer hardware that enables it to remain operational even during a hardware failure. For example, having a RAID1 or RAID5 configuration enables the server to keep running even if one hard disk fails.
Although most FSMO losses can be dealt with within a matter of hours (or even days at some cases), some FSMO roles, such as the PDC Emulator role, should never be offline for more than a few minutes at a time.
What will happen if you keep a FSMO role offline for a long period of time? This table has the info:
The schema cannot be extended. However, in the short term no one will notice a missing Schema Master unless you plan a schema upgrade during that time.
Unless you are going to run DCPROMO, then you will not miss this FSMO role.
Chances are good that the existing DCs will have enough unused RIDs to last some time, unless you’re building hundreds of users or computer object per week.
Will be missed soon. NT 4.0 BDCs will not be able to replicate, there will be no time synchronization in the domain, you will probably not be able to change or troubleshoot group policies and password changes will become a problem.
Group memberships may be incomplete. If you only have one domain, then there will be no impact.
Not necessarily high capacity server – A high-capacity domain controller is one that has comparatively higher processing power than other domain controllers to accommodate the additional work load of holding the operations master role. It has a faster CPU and possibly additional memory and network bandwidth. FSMO roles usually do not place stress on the server’s hardware.
One exception is the performance of the PDC Emulator, mainly when used in Windows 2000 Mixed mode along with old NT 4.0 BDCs. That is why you should:
Increase the size of the DC’s processing power.
Do not make the DC a global catalog server.
Reduce the priority and the weight of the service (SRV) record in DNS to give preference for authentication to other domain controllers in the site.
Do not require that the standby domain controller be a direct replication partner (Seizing the PDC emulator role does not result in lost data, so there is no need to reduce replication latency for a seize operation).
Centrally locate this DC near the majority of the domain users.
You may find these related articles of interest to you: