Win2K Operation Masters

Perhaps unbeknownst to you, a group of domain controllers in your Windows 2000 enterprise quietly works to keep the peace in your network. The functions that this group performs to ensure a serene network are called Operation Master roles. To best administer your Win2K network, you need to learn what Operation Masters do, where to place them throughout your network for optimal performance, and what to do if one fails.

Deal with Conflicts
Win2K Active Directory (AD) supports multimaster replication across all domain controllers. In multimaster replication, each domain controller holds a writable copy of an enterprise's AD, accepts changes to this copy, and replicates the changes to its replication partners. AD has mechanisms that resolve conflicts when users change the same attribute of an object on different domain controllers. For most operations, conflict resolution works well. However, for crucial tasks, such as schema updates, conflict prevention is a more effective process. To facilitate sensitive operations, Win2K provides Operation Masters (aka Flexible Single-Master Operation—FSMO—roles). Each Operation Master handles changes to a specific AD area. Every Win2K enterprise has five Operation Master roles: schema master, domain naming master, PDC emulator, infrastructure master, and Relative Identifier (RID) master. A server can host one or more Operation Master roles. In addition, an administrator can transfer Operation Master roles from one domain controller to another to optimize network operations, and a domain controller can seize a role in the event of a server failure.

Keep the Peace
The schema master and domain naming master are per-forest roles, which means that only one of each role exists in one Win2K forest. The PDC emulator, infrastructure master, and RID master roles are per-domain roles, which means that each domain in a forest requires that these three Operation Master roles are active. To calculate the total number of Operation Master roles for a forest, you can use the formula (n * 3) + 2, where n equals the number of domains. Thus, if you have five domains in your forest, the total number of Operation Master roles is 17 ([5 * 3] + 2 = 17).

By default, Win2K assigns all five roles to the first domain controller installed for the first domain in a new forest. If you add a domain to the forest, the first domain controller holds the three per-domain roles but the per-forest roles remain in the forest root until an administrator manually transfers them.

Schema master. The AD schema defines classes of objects and their attributes. Only one schema exists per forest, and all domains in one forest share the forest's schema. You must carefully plan and implement schema modifications. The schema master role exists to mitigate errors that result when the schema is incorrectly updated. The domain controller that hosts the schema master role is the only domain controller on which you can update the schema. However, you can use the Active Directory Schema Microsoft Management Console (MMC) snap-in on any domain controller to modify the schema as long as the snap-in connects to the schema master. By default, Win2K lets only members of the Schema Administrators group modify the schema.

Domain naming master. To add domains to or remove them from a forest, you must contact the domain naming master. If this Operation Master isn't available, you can't add new domains to or remove existing domains from the forest. The domain naming master is also responsible for the addition and removal of cross-references to domains in external directories, such as external Lightweight Directory Access Protocol (LDAP) directories.

PDC emulator. As its name suggests, the PDC emulator is the only Operation Master role that provides support for legacy Windows NT systems. Each Win2K domain hosts one PDC emulator. The PDC emulator is the preferred domain controller for processing password changes, replicating SAM updates to legacy NT BDCs, and acting as the domain master browser. In addition, the PDC emulator serves as the authoritative time source for all systems in a domain and as the default server for editing group policy and processing changes to the Dfs configuration.

Despite its name, the PDC emulator role doesn't disappear after you upgrade all your systems to Win2K—this role serves as a central reference for password updates in fully upgraded networks running in native mode. Users can change their passwords on any domain controller. After a user makes the change on the domain controller, that domain controller immediately replicates the change to that domain's PDC emulator. This replication takes place right away to ensure that password changes are immediately available to all domain controllers. When a logon attempt fails because of an incorrect password, domain controllers check logon attempts against the PDC emulator before denying the user authentication. Therefore, the PDC emulator needs to have the most recent password updates. However, the replication can cause increased network traffic and logon latency if the PDC emulator communicates with the authenticating domain controller across a WAN link. If this replication behavior is causing problems on your network, you can modify a Registry setting on the domain controllers that perform authentication. In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Registry key, set the AvoidPdcOnWan entry of type REG_DWORD to 1. This value tells the domain controller not to send password changes and validation requests to the PDC emulator if it exists in a different AD site from the domain controller performing the authentication. If the PDC emulator resides in the same AD site, the domain controller still sends changes and validation requests immediately to the PDC emulator.

Infrastructure master. The infrastructure master ensures that domain controllers update cross-domain group-to-user references in a timely manner. Win2K can perform this function without the infrastructure master, but without it the process would take longer to execute. To illustrate the infrastructure master's responsibilities, suppose an administrator changes a user's name in a domain and that user is a member of a group in another domain. Without an infrastructure master, the Active Directory Users and Computers MMC snap-in on the domain controllers in the domain in which the user's group exists wouldn't immediately reflect the name change. The infrastructure master in the domain to which the user's group belongs is responsible for updating the cross-domain references and replicating the updates to the other domain controllers in the domain.

RID master. A unique SID represents each security principal (i.e., user, group, and computer) in AD. A security principal's SID consists of a RID and the domain's unique SID. The RID master allocates to each domain controller in a domain a pool of RIDs from which to create SIDs. When the number of available RIDs falls below a predetermined number (100 by default), the domain controller requests additional RIDs from the domain's RID master. If the RID master is unavailable and a domain controller exhausts its store of RIDs, the domain controller can't create additional security principals.

Operation Master Placement
Win2K will initially decide which domain controllers serve which roles. You'll need to modify the default configuration by transferring roles to other domain controllers (except in the simplest networks).

To start, you need to ensure that you have the appropriate permissions to change server roles. By default, only the Schema Administrators group has the right to change the schema master role owner. The Enterprise Administrators group manages the domain naming master role owner, and the Domain Administrators group has permissions to change role owners for each per-domain Operation Master role.

After you establish that you have the necessary permissions to change server roles, you can use the following guidelines to determine where to place Operation Master roles. First, if enough domain controllers are available in a domain, each domain controller should own only one per-domain role. This setup reduces the load on each domain controller.

Second, although the infrastructure master role needs to have good connectivity to a Global Catalog (GC) server, don't place the role on a GC server. The infrastructure master updates references from objects in its domain to objects in other domains. (The infrastructure master updates references of objects that users have moved or renamed.) The infrastructure master queries the GC server for current information. Therefore, if the infrastructure master and the GC are on the same server, the infrastructure master won't perform an update because the infrastructure master doesn't contain any references to objects that it doesn't hold locally.

Third, at the forest level, the schema master and domain naming master must always be on the same domain controller, and that domain controller must be a GC server. This setup is necessary because the domain naming master must check the GC server for name uniqueness when an administrator adds a new domain. Ensure that this server is physically secure and located near the administrators who are responsible for schema changes and adding and removing domains.

To illustrate the proper placement of Operation Masters, I'll use a fictitious company called Brady.com. It contains multiple domains and has three main locations: Headquarters, IT, and Manufacturing. WAN links connect the three locations. As Figure 1 illustrates, I placed the two forest-based Operation Masters, schema master and domain naming master, in the IT location to ensure that the administrators who are responsible for schema updates and domain management were well connected to those domain controllers. I also placed the PDC emulator and RID master at the IT location. I placed these Operation Master roles on separate servers to balance the load that communication to and from these servers creates and, in case of single-server failure, to prevent two Operation Masters from becoming unavailable. Finally, I placed the infrastructure master on a subnet that provided good connectivity to a GC server.

   Previous  [1]  2  3  Next