Recipe15.19.Transferring or Seizing a FSMO Role

Recipe 15.19. Transferring or Seizing a FSMO Role

Problem

You want to transfer a FSMO role to a different domain controller. This is necessary if you need to take a current FSMO role holder down for maintenance. If a current FSMO role holder is unavailable, you'll need to seize the role on another domain controller.

Solution

Using a graphical user interface

Use the same directions as described in Recipe 15.18 for viewing a specific FSMO, except target (i.e., right-click and select Connect to Domain Controller) the domain controller you want to transfer the FSMO to before selecting Operations Master.
Click the Change button.
Click OK twice.
You should then see a message stating whether the transfer was successful.

Using a command-line interface

The following transfers the PDC Emulator role to <NewRoleOwner>. See the discussion for more about transferring the other roles:

> ntdsutil roles conn "co t s <NewRoleOwner>" q "TRansfer PDC" q q

The following seizes the PDC Emulator role to run on <NewRoleOwner>:

> ntdsutil roles conn "co t s <NewRoleOwner>" q "seize PDC" q q

Using VBScript

' This code transfers the PDC Emulator role to the specified owner.  ' See the discussion to see about transferring the other roles. ' ------ SCRIPT CONFIGURATION ------ strNewOwner = "<NewRoleOwner>"  ' e.g., dc2.rallencorp.com ' ------ END CONFIGURATION --------- Set objRootDSE = GetObject("LDAP://" & strNewOwner & "/RootDSE") objRootDSE.Put "becomePDC", 1 objRootDSE.SetInfo

Seizing a FSMO role is typically not something you need to do programmatically, but you can do it. All you need to do is set the fSMORoleOwner attribute for the object that represents the FSMO role as described in Recipe 15.18 with the distinguished name of ntdSDSA object of the new role owner.

Discussion

The first domain controller in a new forest is assigned the two forest-wide FSMO roles (schema and domain naming). The first domain controller in a new domain gets the other three domain-wide roles. It is very likely you'll need to move the roles around to different domain controllers at some point. Also, when you need to take down a domain controller that is currently a FSMO role owner, you'll want to transfer the role beforehand. If you plan to install a hotfix or do some other type of maintenance that necessitates only a quick reboot, you may not want to go to the trouble of transferring the FSMO role.

Some FSMO roles are more time critical than others. For example, the PDC Emulator role is used extensively, but the Schema Master is needed only when extending the schema. If a FSMO role owner becomes unavailable before you can transfer it, you'll need to seize the role.

Seizing a FSMO role should not be done lightly. The general recommendation is to seize a FSMO role only when you cannot possibly bring the previous role holder back online. One reason that seizing a role is problematic is that you could possibly lose data. For example, let's say that you extended the schema and immediately after it was extended, the Schema FSMO went down. If you could not bring that server back online, those extensions may have not replicated before the server went down. You would need to determine if the schema extensions replicated and, if not, re-extend the schema. A similar problem can result from losing the RID FSMO, where duplicate RID pools may be allocated.

Using a command-line interface

Any role can be transferred using nTDsutil by replacing "transfer PDC" in the solution with one of the following:

"transfer domain naming master"
"transfer infrastructure master"
"transfer RID master"
"transfer schema master"

Using VBScript

FSMO roles can be transferred programmatically by setting the become<FSMORole> operational attribute on the RootDSE of the domain controller to transfer the role to. The following are the available attributes that can be set that correspond to each FSMO role:

becomeDomainMaster
becomeInfrastructureMaster
becomePDC
becomeRidMaster
becomeSchemaMaster