3.27. Seizing a FSMO Role

Problem

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

Solution

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”

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.

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 ...

Get Active Directory Cookbook now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.