A role seizure is controlled through the same per-role object permissions that controls role transfers, plus the Write fsmoRoleOwner property permission at the new role owner. To seize a role, you need both the per-role object permission and the Write fsmoRoleOwner property permission. By default, the Write fsmoRoleOwner property permission is granted to the same groups that are granted the per-role object permissions.
A role seizure is a two-step process. In the first step, you must determine whether the domain controller that seizes the role is fully up-to-date with the updates performed on the previous role owner by using the Repadmin command-line tool. After you have determined the status of the domain controller seizing the role, you can seize the operations master role by using the Ntdsutil utility.
Caution Do not seize an operations master role if you can transfer it instead. Seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again.
Determining the Status of the Domain Controller Seizing the Role
The domain controller that seizes the role must be fully up-to-date with the updates performed on the previous role owner. Because of replication latency, it is possible that the domain controller might not be up-to-date. To check the status of updates for a domain controller, use the Repadmin.exe: Replication Diagnostics command-line tool, included with the Windows Support Tools on the Windows Server 2003 CD-ROM in the \Support\Tools folder.
Note For detailed instructions on installing the Windows Support Tools, refer to Chapter 3, "Administering Active Directory."
For example, to make sure a domain controller is fully up-to-date, suppose that "serverl" is the RID master of the domain microsoft.com, "server2" is the standby operations master domain controller, and "server3" is the only other domain controller in the microsoft.com domain. Using the Repadmin tool along with the /Showutdvec argument, you would issue the following commands, shown in bold:
The output for serverl is especially relevant. Server2's up-to-date status value with respect to serverl (serverl @ USN 2604) is larger than server's up-to-date status value with respect to serverl (serverl @ USN 2590), making it safe for server2 to seize the RID master role formerly held by serverl. If the up-to-date status value for server2 was less than the value for server3, you would wait for normal replication to update server2, or use the Repadmin tool's /Syncall commands to make the replication happen immedi¬ately. You can learn more about using Repadmin in Windows Support Tcx)ls help.
