Responding to operations master failures

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

Responding to operations master failures

Some of the operations master roles are crucial to the operation of your network. Others can be unavailable for quite some time before their absence becomes a problem. Generally, you will notice that a single master operations role holder is unavailable when you try to perform some function controlled by the particular operations master.

If an operations master is not available due to computer failure or network problems, you can seize the operations master role. This is also referred to as forcing the transfer of the operations master role. Do not seize the operations master role if you can transfer it instead. For more information, see Transferring operations master roles.

Note

  • The operations master roles are sometimes called flexible single master operations (FSMO) roles.

Before forcing the transfer, first determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online.

In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable. The impact of various role holder failures is discussed in the following topics.

Schema master failure

Temporary loss of the schema master is not visible to network users. It will not be visible to network administrators either, unless they are trying to modify the schema or install an application that modifies the schema during installation.

If the schema master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the schema master is permanent.

Important

  • A domain controller whose schema master role has been seized must never be brought back online.

For procedures on how to seize the schema master role, see Seize the schema master role.

Domain naming master failure

Temporary loss of the domain naming master is not visible to network users. It will not be visible to network administrators either, unless they are trying to add a domain to the forest or remove a domain from the forest.

If the domain naming master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the domain naming master is permanent.

Important

  • A domain controller whose domain naming master role has been seized must never be brought back online.

For procedures on how to seize the domain naming master role, see Seize the domain naming master role.

RID master failure

Temporary loss of the RID master is not visible to network users. It will not be visible to network administrators either, unless they are creating objects and the domain in which they are creating the objects runs out of relative IDs (RIDs).

If the RID master will be unavailable for an unacceptable length of time, you can seize the role to the operations master. However, seizing this role is a drastic step that you should take only when the failure of the RID master is permanent.

Important

  • A domain controller whose RID master role has been seized must never be brought back online.

For procedures on how to seize the RID master role, see Seize the RID master role.

PDC emulator master failure

The severity of a PDC outage depends on your Service Level Agreement (SLA) and the actual behavior and configuration of the environment. For example, inconsistent password change behavior may affect users beyond what your SLAs allow, or the lack of time synchronization may cause resource access failures.

Also, in smaller environments, it may happen that the PDC as the first server in the domain is the only DNS or Global Catalog Server, or is the only domain controller (DC) with a valid SYSVOL in case other DCs did not successfully initiate or maintain SYSVOL replication. The PDC role holder may also be the target for regular file server access. When this is done for folder redirection or logon script activities, it may also affect users when logging on and while they work.

Other than the conditions described above, there is no direct dependency of the domain members on the PDC role holder. However, you might be using applications that are coded to contact the PDC only. You should try to avoid having this single point of failure.

Often, these applications were written for Windows NT 3.x and 4.0 deployments where the PDC was the only writable DC. However, since Active Directory, all DCs except Read-Only DCs are writable. The DsGetDcName API allows you to pick the right type; similar options are available in AD API interfaces like ADSI (ADS_READONLY_SERVER) or the .NET runtime.

The loss of the primary domain controller (PDC) emulator master may affect network users. Therefore, when the PDC emulator master is not available, you may need to immediately seize the role.

For procedures on how to seize the PDC emulator role, see Seize the PDC emulator role.

Infrastructure master failure

Temporary loss of the infrastructure master is not visible to network users. It will not be visible to network administrators either, unless they have recently moved or renamed a large number of accounts.

If the infrastructure master will be unavailable for an unacceptable length of time, you can seize the role to a domain controller that is not a global catalog but is well connected to a global catalog (from any domain), ideally in the same site as the current global catalog. When the original infrastructure master is returned to service, you can transfer the role back to the original domain controller.

For procedures on how to seize the infrastructure master role, see Seize the infrastructure master role.

For general information about operations masters, see Operations master roles.