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.