Seize the day (with FSMOs)

Learn a procedure called "seizing", an emergency procedure for moving FSMO roles to a different Windows server.

In my last tip, I discussed how to smoothly transfer FSMO roles from one server to another. Unfortunately, life and networks are rarely simple and easy. All too often you'll find yourself in the position of needing to forcibly move the FSMO roles when the current host server is offline. The act of forcibly moving the FSMO to a new server host is called seizing.

Seizing an FSMO role should only be performed in extreme circumstances. Your primary FSMO role server host should be permanently inaccessible, offline, or irreparably damaged. If the original FSMO host is ever returned to the network, there can be some serious problems to deal with (more about that later). While FSMO transfer can be handled through GUI Windows interfaces, FSMO seizure is easiest when performed from a command line.

To seize the role of Schema Master, perform the following steps from a command prompt from the new destination server:

  1. Run NTDSUTIL.
  2. Then enter "roles" [Enter], then "connections" [Enter], then "connect to sever <servername>" [Enter].
  3. Enter "qui" [Enter], then "seize schema master" [Enter].

Once this process is complete, the Schema Master role will be forcibly moved to its new server host. Be sure not to allow the previous Schema Master system to return to the network, otherwise an authority conflict will occur. If you want to return the old system to the network, first demote it to a member server before reconnecting it to the network.

Seizing the roles of Domain Naming Master, PDC Emulator, Infrastructure Master and RID master all follow the same steps as for seizing the Schema Master. Simply change the last action command to "seize domain naming master", "seize PDC", "seize infrastructure master" and "seize rid master" respectively.

Returning a previous host for one of these FSMO roles is not as disastrous as that of the Schema Master. However, it should still be avoided. Always demote previous FSMO role hosts to member servers before returning them to the network. Once returned, they can be re-promoted to a domain controller without causing conflicts.


James Michael Stewart is a partner and researcher for ITinfopros, a technology-focused writing and training organization.


This was first published in September 2003

Dig deeper on Windows Server Monitoring and Administration

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close