Recipe 3.27 Seizing a FSMO Role

3.27.1 Problem

You need to seize a FSMO role because the current role holder is down and will not be restored.

3.27.2 Solution

3.27.2.1 Using a command-line interface

The following would seize the PDC Emulator role to <NewRoleOwner>:

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

Any of the other roles can be transferred as well using ntdsutil by replacing "transfer PDC" in the previous solution with one of the following:

• "seize domain naming master"

• "seize infrastructure master"

• "seize RID master"

• "seize schema master"

3.27.2.2 Using VBScript

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 3.25 with the distinguished name of nTDSDSA object of the new role owner.

3.27.3 Discussion

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, lets 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 any of 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. See Recipe 2.24 for more information.

3.27.4 See Also

Recipe 3.25 for finding FSMO role holders, Recipe 3.26 for transferring a FSMO role, MS KB 223787 (Flexible Single Master Operation Transfer and Seizure Process), and MS KB 255504 (Using Ntdsutil.exe to Seize or Transfer FSMO Roles to a Domain Controller)