You need to seize a FSMO role because the current role holder is down and will not be restored.
The following would seize the PDC Emulator role to
> 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
“seize domain naming master”
“seize infrastructure master”
“seize RID master”
“seize schema master”
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.
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 ...