Flexible Single Master Operations Roles

Flexible Single Master Operations Roles

Flexible Single Master Operations (FSMO) Roles are specialized services within Active Directory Domain Services that should be performed only by a single domain controller at a time.The word flexible refers to the ability to transfer the FSMO role to another domain controller, despite the fact that only one domain controller can host a FSMO role at a time. Because of this flexibility, you not only have the option of transferring the role to another domain controller if the original role holder goes down, but also the ability to plan which domain controller will hold the role, thus optimizing your network.

For the most parts, Active Directory Domain Services has redundancy in place which allow the changes to be made on any domain controller but FSMO roles are single point of failure since only one domain controller can hold a role at a time.

There are five roles that make up FSMO:

  1. Schema Master
  2. Domain Naming Master
  3. Infrastructure Master
  4. Relative Identifier (RID) Master
  5. Primary Domain Controller (PDC) Emulator

All five of these roles can coexist on one domain controller, or you can move them so that they all run on their own independent domain controller. Before transferring a role, you should consider the interaction between some of the roles, as well as how they interact with other AD DS services.

Schema Master

All of the domain controllers within the domain allow administrators to create and make changes to the objects contained within the domain. As an administrator creates an object (e.g. a computer or user account), the schema controls how the object is built. Because all the domain controllers within the forest share the same Schema, every object that is created from an object class contains the same attributes. Domain controllers work as peers to one another; as changes are made to attributes within the objects, the changes are replicated to other domain controllers. The only problem with this model is that two administrators can make changes at the same time and cause a replication problem.

The designers of AD DS realized that allowing two or more administrators to change schema information could render objects, and possibly the entire domain or forest, completely useless.

To protect the schema from the corruption that could be caused by more than one administrator attempting to make changes to the schema on multiple domain controllers, the Schema Master was introduced. The Schema Master is the one domain controller within the forest that is allowed to access and modify the portion of the AD DS database that holds the schema. The schema partition, sometimes known as the schema naming context, resides on every domain controller within the forest, but can be modified only on one domain controller which is hosting the Schema Master role.

By default, the Schema Master is the first domain controller that is promoted within the forest. As a matter of fact, all five of the FSMO roles are held on this single server until you transfer them. For most installations, the first domain controller can continue to participate as the Schema Master until you decide to decommission the system at the end of the hardware or system life cycle. Because the Schema Master is not heavily used, it does not have large resource requirements.

Besides being the central location for changes to the schema, the Schema Master is required to be online when the forest functional level is raised. Keep this in mind as you are in the process of adding Active Directory based applications such as Microsoft Exchange Server, System Center Configuration Manager, Microsoft Operations Manager, and others or when you are in the process of decommissioning the Windows NT 4 and Windows 2000 based domain controllers. If the Schema Master is not online, you will not be able to perform certain necessary functions.

Domain Naming Master

Similar to the Schema Master, there is only one Domain Naming Master within the forest. The Domain Naming Master is the system that is responsible for making sure that domain names are unique and available when you’re adding or removing domains from your forest. Typically this is not a FSMO role that is used very often once the organization’s forest structure has been built and stabilized.
Because there is only one Domain Naming Master, it is important that the role be  available as domains are created and removed, yet it does not consume very much in the way of resources on the system where it resides. And, just like Schema Master, you can leave this FSMO role on the first domain controller within the forest for as long as necessary. Once you deem it necessary to decommission the server running this role, determine which server will be responsible for hosting the Domain Naming Master role.

If the domain controller that is holding Domain Naming Master role fails, you can usually go without the role until you can bring the domain controller online again. If you do need to create a new domain or decommission an existing domain, you can seize this role on another system.

Infrastructure Master

Whereas the Schema Master and the Domain Naming Master can reside on only one domain controller within the entire forest, the Infrastructure Master, Relative ID Master and PDC Emulator roles can be found within every domain in the forest. When you install the first domain controller for the forest, these roles are installed. When you add additional domains to your forest, each one will have these roles installed on the first domain controller within each domain.

The Infrastructure Master is an interesting role. Its job is to check other domains in the forest for changes to objects. If it finds a change to an object in another domain, it will update the attributes for any instances of that object, and then the changes will be replicated to other domain controllers from its domain.

Why would the object be contained in more than one domain?

If an object is used within an access control list or as a member of a group, changes to the object within the other domain will not replicate to any other domains by default. The global catalog will pick up the change due to the intra-domain replication that global catalogs participate in, but the non-global catalog domain controllers will not receive any domain partition updates. If Infrastructure Master were to fail, you might not miss it for several days, depending on the size of your environment. If you were making several changes to objects within your forest on a daily basis, you might miss this function because the changes would not propagate immediately. However, the environments that do not implement many changes might not notice the failure of this role instantly.

Relative Identifier (RID) Master

As already mentioned, RID Master is one of the roles that is available in each domain. It is responsible for making sure that each security principal within the domain has a unique identifier. This identifier is actually a number that is incremented for each object that can be created within the domain. Because each object takes on the security identifier (SID) of the domain for identification purposes, the relative identifier (RID) uniquely identifies the security principal within the domain.

It is important to note that the RID Master is not contacted for each RID that is handed out when an account is created. Instead, domain controllers contact the RID Master when they are promoted, and the RID Master allocates a large block of RIDs to the domain controller. When the domain controller is close to depleting the RIDs it has been allocated, the domain controller contacts the RID Master again to replenish its RID pool.

With the original implementation of Active Directory in Windows 2000, the RID pool allocation was 500 RIDs per domain controller, and the domain controllers would contact the RID Master when twenty percent of their RID pool remained. There were implementations in which this scenario caused problems. If an import utility such as
csvde or ldifde were in use or if the Active Directory Migration Tool were used, the RID pool could potentially become depleted before the domain controller received a new allocation of RIDs. To solve this problem, Windows 2000 Service Pack 4 changed the allocation-request limit to fifty percent. Windows Server 2003 and later versions all adhere to the same criteria.

Availability of the RID Master is important. Domain controllers responsible for creating accounts need to obtain their allocation of RIDs from the RID Master as their RID pool becomes depleted. If the RID Master is not available, the domain controllers will not be able to get any new RIDs.

Primary Domain Controller (PDC) Emulator

The name of this role is a little misleading because there are several other functions that this role provides besides acting as the PDC for Windows NT 4 domain controllers, it also help in time synchronization and password changes across the domain.

Whenever a domain is in mixed mode and Windows NT 4 Backup Domain Controllers (BDCs) exist within the domain, the PDC Emulator is responsible for keeping the Windows NT 4 BDCs and all other Windows 2000, 2003, and 2008 domain controllers updated. The PDC Emulator is also responsible for accepting password-change requests from pre–Active Directory clients. If the domain is placed in Windows 2000 native mode or the Windows Server 2003 functional level, the PDC Emulator becomes the clearinghouse for password changes within the domain. Any time another domain controller receives a password change from a client, the PDC Emulator is passed the change so that the other domain controllers can be notified of the change. If a user has entered a bad password, the authentication request is passed to the PDC Emulator to validate that the user’s password was not changed on another domain controller prior to the authentication attempt.

By default the PDC Emulator is the domain controller that is responsible for making updates to group policies and is the master replication point when changes are made. Group Policy Objects (GPOs) consist of two parts: the Group Policy Container, which is an object that exists within AD DS, and the Group Policy Template, which is the configuration data for the GPO that resides within the sysvol directory. As changes are made by an administrator, the changes are effected on the PDC Emulator, and then they are replicated to the PDC Emulator’s replication partners.

FSMO Roles Placement

Because of the importance of the FSMO roles, you should carefully choose where the domain controllers holding each of these roles are placed. Certain functions don’t work well together; when placing the FSMO roles, consider the functional level of the domain and forest.

Operations Masters in a Single-Domain Forest

Within a single-domain forest, the Infrastructure Master does not play a very important role. As a matter of fact, its services are not used at all. Because you don’t have any remote domains to which the infrastructure master can compare domain information, it doesn’t matter whether the domain controller is a global catalog server. In fact, in a single-domain environment, all domain controllers could be enabled as global catalog servers because there will be no additional replication costs. By default, the first domain controller within the domain will hold all the FSMO roles and will also be a global catalog server. You should designate another domain controller as a standby server. You do not have to configure anything special on this second domain controller.

Operations Master Site Placement in a Multiple-Domain Forest

The five FSMO roles will have to be placed on domain controllers where they will be the most effective. You should take certain criteria into consideration when you are deciding on which site these domain controllers will be placed.

Forestwide Roles

The two forestwide roles (Schema Master and Domain Naming Master) don’t have a lot to do after the forest is stabilized, so they don’t really require the high availability like the other three roles require.

Schema Master Placement

The Schema Master role is not used very often. Typically, the only time the Schema Master needs to be online after the initial installation of AD DS is when you are making changes to the schema or when the functional level of the forest is raised. You should place the Schema Master in a site where the schema administrators have easy access to it. You want to make sure that the changes made to the schema are done on a domain controller that is accessible within the same LAN-based infrastructure as the administrator making the change. Doing so makes sense from administrative and security standpoints. For security reasons, you don’t want the schema changes that you are making traveling across a potentially vulnerable network connection.

Also, consider the replication that will be incurred when a change is made. For this reason alone, you may want to place the Schema Master within a site that has the most domain controllers within the forest. As replication is initiated due to schema changes, if you have the Schema Master located close to a majority of the domain controllers within the domain, the replication will be done on the LAN segments and the amount of traffic on WAN link will be reduced.

Domain Naming Master Placement

Like the Schema Master, the Domain Naming Master is not used very often. Its role is to guarantee the uniqueness of domain names within the forest. It is also used when removing domains from the forest. For the Domain Naming Master to perform its function, it must be able to check in with a global catalog server. The global catalog server holds information from every domain within the forest, and when a new domain is added to the forest or a domain is decommissioned, the Domain Naming Master is responsible for identifying the domain information, making sure it is unique, and then updating the configuration information.

If the domain controller holding the Domain Naming Master role is a Windows 2000–based server, you should locate it on a global catalog server. Microsoft made changes to Windows Server 2003–based domain controllers to allow them to contact a global catalog server instead of having the Domain Naming Master reside on a global catalog server. This is the case with Windows Server 2008 as well.
The Domain Naming Master can be located on the same domain controller as the Schema Master because neither of the roles impacts the way the domain controller functions. As with the Schema Master, the Domain Naming Master should be located close to where the administrative staff has access, even though this role does not incur the replication costs that the Schema Master does.

Domainwide Roles

The domainwide roles tend to be used a little more often, and to require that the domain controller holding the roles be highly available. When planning the hardware that will be used for these domain controllers, make sure that it is highly reliable.

Infrastructure Master

The Infrastructure Master holds a very important role within a multiple-domain forest. If users from one domain are added to the membership of groups from a second domain, the Infrastructure Master is then responsible for maintaining any updates when changes occur within the remote domain.

For example, if a user from Domain A is added to a group in Domain B, and the user’s name changes after marriage, the user’s account name in Domain A will not match the entry within the group membership of Domain B. The Infrastructure Master is responsible for reviewing the information from Domain A and checking for discrepancies. If it finds that a change has been made, the Infrastructure Master updates the information in Domain B so that the new name information within the group can be replicated to all the domain controllers.

If the Infrastructure Master is located on a global catalog server, it checks for differences between Domain A and Domain B, but it won’t notice any discrepancies because the global catalog server hosts information from Domain A. Other servers that are not global catalog servers in Domain B won’t have the correct information for the group, and the Infrastructure Master won’t update the other domain controllers. So, in a multiple-domain forest, move the Infrastructure Master to a domain controller that is not a global catalog server. Of course, if you make every domain controller a global catalog server, you don’t have to worry about the Infrastructure Master placement because every domain controller hosts information from every domain and replicates changes whenever they are made.

RID Master

The RID Master is responsible for generating and maintaining the RIDs used by the security principals within the domain. Each domain controller will contact the RID Master to obtain a group of RIDs to be used as the accounts are created. If your domain is in native mode or higher, you should place the RID Master in a site that has domain controllers where administrators are creating a majority of the accounts. This allows the RID Master to efficiently hand out allocations of RIDs to the domain controllers performing most of the account-creation work. If your domain is in mixed mode, consider placing the RID Master on the same server as the PDC emulator. The PDC emulator is the only domain controller that can create accounts within the domain when the domain is in mixed mode.

Because the RID Master is responsible for handing out the RIDs for all the accounts that are created within the domain, you should designate a standby server so that you can seize the role quickly if necessary. As mentioned earlier, the standby server should be a direct replication partner to the original RID Master so that any updates to the RID Master are known to the standby server.

PDC Emulator

The RID Master is a highly utilized FSMO role, but the PDC Emulator is the busiest role of all. The domain controller hosting PDC Emulator role should be highly available and definitely have a standby server available. When a PDC Emulator goes down, you want to make sure you can seize the role quickly so that you do not lose the functionality it provides.

If you are making several changes to group policies, position the role close to the administrators responsible for making the updates to GPOs. This keeps the updates local for the administrators. However, if you have a majority of your domain controllers at a site other than where the administrators are located, you have to decide whether the replication cost of GPO updates outweighs local administration.

Keep in mind that whenever a user changes her or his password, the PDC Emulator is immediately notified of the change. When a user’s credentials are sent to a domain controller that has not been updated with the new password, the domain controller will check with the PDC Emulator before incrementing the account-lockout counter and potentially locking out the user. Because of this additional traffic, consider placing the PDC Emulator close to a majority of the user accounts within the domain.

Identifying the Role Holders

There are several ways to find out which domain controller holds a FSMO role. One of the easiest ways to find out which domain controller is hosting a FSMO role is to use the built-in Active Directory utilities. Most of the Active Directory utilities are easy to find and work with, but one of them is hidden from view.

Identify Domain-wide Roles using GUI

You can use the Active Directory Users and Computers utility to find the domain controllers that hold domain-wide roles as shown below:

Open Active Directory Users and Computers console and right click the Active Directory Users and Computers option at top. In the context menu, select All Tasks and then Operation Masters as shown in diagram

Identify Domain-wide Roles using AD Users and Computers utility

Identify Domain-wide Roles using AD Users and Computers utility

The Roles will be listed in three different tabs with the name of current role holder domain controller.

FSMO Role Holder

FSMO Role Holder

The name of current Role holder is marked red. Notice the Change button, you can transfer the roles using Change button.

Identify Forest-wide Role (Domain Naming Master)

The Domain Naming Master role can be identified by using Active Directory Domains and Trusts utility. The process is same as we did to identify domain-wide roles.

Identify Forest-wide Roles using Active Directory Domain and Trusts utility

Identify Forest-wide Roles using Active Directory Domain and Trusts utility

Domain Naming Master Role Holder

Domain Naming Master Role Holder

You can transfer the role to other domain controller by clicking change button.

Identify Forest-wide Role (Schema Master)

This is the role that is not available to administrators unless they choose to register the dynamic link library (DLL) necessary for it to be displayed and used. The designers of Active Directory did this intentionally because they did not believe the tool should be available to every administrator within the forest. Instead, Microsoft forces anyone who wants to use this tool to research how to get to the schema. Because the schema should not be altered unless there is a valid business case for doing so, this snap-in would not be used very often anyway. To gain access to the Active Directory Schema snap-in, you will need to register it using the following command from elevated command prompt.

regsvr32 schmmgmt.dll

If the above command is successful, you will receive a message as shown below:

Schema Management DLL Registration Success

Schema Management DLL Registration Success

If you do not run the command using domain administrator privileges, you will see he following error:

Schema Management DLL Registration Failed

Schema Management DLL Registration Failed

Once the DLL is registered, follow the steps given below:

  1. Click Start , click Run , type mmc , and then click OK .
  2. On the File menu, click Add/Remove Snap-in .
  3. Under Available snap-ins , click Active Directory Schema , click Add , and then click OK .
  4. Right click Active Directory Schema option and select Operation Masters from context menu as shown below:
    Identify Schema Master Role using MMC Snapin

    Identify Schema Master Role using MMC Snapin

  5. You will see the current Schema Master Role holder. You can click change button to transfer the role to another domain controller.
    Schema Master Role Holder

    Schema Master Role Holder

  6. Close the MMC console. Click No when asked to save the console.
Identify Domain-wide Roles using Command-line

You can use netdom command to identify the current role holders. The command syntax is as shown below:

C:\>netdom query fsmo /domain:airvoice.local
Schema master               DC1.airvoice.local
Domain naming master        DC1.airvoice.local
PDC                         DC1.airvoice.local
RID pool manager            DC1.airvoice.local
Infrastructure master       DC1.airvoice.local
The command completed successfully.

Replace airvoice.local with your own domain name. This returns a list of all the role
holders in a single command.

To find individual role holders, you can use dsquery command,as shown below:

  • To find the Schema Master: dsquery server -hasfsmo schema
C:\>dsquery server -hasfsmo schema
"CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=airvoice,DC=local"
  • To find the Domain Naming Master: dsquery server -hasfsmo name
  • To find the Infrastructure Master: dsquery server -hasfsmo infr
  • To find the RID Master: dsquery server -hasfsmo rid
  • To find the PDC Emulator: dsquery server -hasfsmo pdc

Maintaining the FSMO Roles

There are reasons to move a role from one domain controller to another. Many organizations need to move at least one role because they have more than one domain in their forest. The Infrastructure Master cannot work effectively on a global catalog server when there are two or more domains.

Depending on your situation, you can transfer the role to another domain controller if the original role holder is still online, or you can seize, which means forcibly grabbing the role if the original role holder has failed. Transferring the role is the preferred method because it performs a controlled switch-over from one domain controller to the next. You should consider seizing a role only if the original role holder cannot be brought back online. Of course, safeguards are in place to protect the forest or domain from data corruption should the original role holder come back online, but you shouldn’t take a chance. If the original role holder has failed and you have seized the role on another domain controller, do not attempt to bring the original role holder back online until you can remove that role from the server.

Transferring the Role to Another Domain Controller

If you are demoting a role holder, make sure that you transfer the role to another domain controller, preferably the domain controller you have designated as the standby role holder. Doing so guarantees that you are transferring the role to the appropriate domain controller.

Transferring the RID Master, PDC Emulator, and Infrastructure Masters via GUI

To Transfer the Domain-wide RID Master, PDC Emulator and Infrastructure Master FSMO Roles:

  1. Open the Active Directory Users and Computers snap-in from the Administrative Tools folder.
  2. If you are not logged onto the target domain controller, in the snap-in, right-click the icon next to Active Directory Users and Computers and press Connect to Domain Controller.
  3. Select the domain controller that will be the new role holder, the target, and press OK.
  4. Right-click the Active Directory Users and Computers icon again and press Operation Masters.
  5. Select the appropriate tab for the role you wish to transfer and press the Change button.
  6. Press OK to confirm the change.
  7. Press OK all the way out.
Transferring the Domain Naming Master via GUI

To Transfer the Domain Naming Master Role:

  1. Open the Active Directory Domains and Trusts snap-in from the Administrative Tools folder.
  2. If you are not logged onto the target domain controller, in the snap-in, right-click the icon next to
    Active Directory Domains and Trusts and press Connect to Domain Controller.
  3. Select the domain controller that will be the new role holder and press OK.
  4. Right-click the Active Directory Domains and Trusts icon again and press Operation Masters.
  5. Press the Change button.
  6. Press OK to confirm the change.
  7. Press OK all the way out.
Transferring the Schema Master via GUI

To Transfer the Schema Master Role:

  1. Register the Schema management DLL if not already done. Run the command regsvr32 schmmgmt.dll from elevated command prompt.
  2. Press OK. You should receive a success confirmation.
  3. From the Run command open an MMC Console by typing MMC.
  4. On the Console menu, press Add/Remove Snap-in.
  5. Press Add. Select Active Directory Schema.
  6. Press Add and press Close. Press OK.
  7. If you are not logged onto the target domain controller, in the snap-in, right-click the Active Directory Schema icon in the Console Root and press Change Domain Controller.
  8. Press Specify…. and type the name of the new role holder. Press OK.
  9. Right-click right-click the Active Directory Schema icon again and press Operation Masters.
  10. Press the Change button.
  11. Press OK all the way out.
Transferring the FSMO Roles via Ntdsutil.exe

Ntdsutil.exe is a command-line tool that provides management facilities for Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS). You can use the ntdsutil commands to perform database maintenance of AD DS, manage and control single master operations, and remove metadata left behind by domain controllers that were removed from the network without being properly uninstalled.

Caution: NTDSUtil tool is intended for use by experienced administrators. Using this utility incorrectly may result in partial or complete loss of Active Directory functionality.

Log on to a domain controller that is located in the forest where FSMO roles are being transferred. We recommend that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user should be a member of the Enterprise Administrators group to transfer Schema master or Domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the Infrastructure master roles are being transferred.

a). Click Start, and type cmd in the search box, then right click the cmd.exe and select Run as Administrator. In command prompt type ntdsutil and press enter.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>ntdsutil
ntdsutil:

b). Type roles, and then press ENTER.

ntdsutil: roles
fsmo maintenance:

c).  Type connections, and then press ENTER.

fsmo maintenance: connections
server connections:

d). Type connect to server server_name, where the server_name is the name of the domain controller you want to assign the FSMO role to and then press ENTER.

server connections: connect to server DC2
Binding to DC2 ...
Connected to DC2 using credentials of locally logged on user.
server connections:

e). At the server connections: prompt, type q, and then press ENTER again.

Binding to DC2 ...
Connected to DC2 using credentials of locally logged on user.
server connections: q
fsmo maintenance:

f). Type transfer role, where role is the role that you want to transfer. For a list of roles that you can transfer, type ? at the fsmo maintenance prompt, and then press ENTER as shown below:

fsmo maintenance: ?

 ?                             - Show this help information
 Connections                   - Connect to a specific AD DC/LDS instance
 Help                          - Show this help information
 Quit                          - Return to the prior menu
 Seize infrastructure master   - Overwrite infrastructure role on connected server
 Seize naming master           - Overwrite Naming Master role on connected server
 Seize PDC                     - Overwrite PDC role on connected server
 Seize RID master              - Overwrite RID role on connected server
 Seize schema master           - Overwrite schema role on connected server
 Select operation target       - Select sites, servers, domains, roles and
                                 naming contexts
 Transfer infrastructure master - Make connected server the infrastructure master
 Transfer naming master        - Make connected server the naming master
 Transfer PDC                  - Make connected server the PDC 
 Transfer RID master           - Make connected server the RID master
 Transfer schema master        - Make connected server the schema master

fsmo maintenance:

For example, to transfer the RID master role, type transfer rid master.  You will see a warning popup asking if you want to perform the transfer. Select Yes to continue.

g). After you transfer the roles, type q and press ENTER until you quit Ntdsutil.exe and then restart the server and update your backups.

Seize the FSMO Roles via Ntdsutil.exe

If the original role holder becomes unavailable and you deem it necessary to have the standby server become the role holder, you can seize the role on the standby server. Again, this is a drastic measure and should be performed only if you are certain the original role holder is not going to be reintroduced on the network. (If you are taking a domain controller offline permanently, whether or not it is a role holder, you should demote it so the references to the domain controller are removed from Active Directory.)

I would prefer to use transferring the FSMO roles instead of Seize. But there might be situations like if your current role holder is permanently crashed and can not be returned back online. In these situations you can  use ntdsutil to seize the roles.

Log on to a domain controller that is located in the forest where FSMO roles are being transferred. We recommend that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user should be a member of the Enterprise Administrators group to transfer Schema master or Domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the Infrastructure master roles are being transferred.

a). Click Start, and type cmd in the search box, then right click the cmd.exe and select Run as Administrator. In command prompt type ntdsutil and press enter.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>ntdsutil
ntdsutil:

b). Type roles, and then press ENTER.

ntdsutil: roles
fsmo maintenance:

c).  Type connections, and then press ENTER.

fsmo maintenance: connections
server connections:

d). Type connect to server server_name, where the server_name is the name of the domain controller you want to assign the FSMO role to and then press ENTER.

server connections: connect to server DC2
Binding to DC2 ...
Connected to DC2 using credentials of locally logged on user.
server connections:

e). At the server connections: prompt, type q, and then press ENTER again.

Binding to DC2 ...
Connected to DC2 using credentials of locally logged on user.
server connections: q
fsmo maintenance:

f). Type seize role, where role is the role that you want to transfer. For a list of roles that you can transfer, type ? at the fsmo maintenance prompt, and then press ENTER as shown below:

fsmo maintenance: ?

 ?                             - Show this help information
 Connections                   - Connect to a specific AD DC/LDS instance
 Help                          - Show this help information
 Quit                          - Return to the prior menu
 Seize infrastructure master   - Overwrite infrastructure role on connected server
 Seize naming master           - Overwrite Naming Master role on connected server
 Seize PDC                     - Overwrite PDC role on connected server
 Seize RID master              - Overwrite RID role on connected server
 Seize schema master           - Overwrite schema role on connected server

[output cut]

For example, to transfer the RID master role, type seize rid master.  You will see a warning popup asking if you want to perform the transfer. Select Yes to continue.

g). After you seize the roles, type q and press ENTER until you quit Ntdsutil.exe and then restart the server and update your backups.

Although Microsoft has done a perfect job of developing a stable active directory service, things happen with any type of file, service, or database that can cause problems and ultimately get corrupted. In the next section, we will look into the troubleshooting steps and tools that help you assess and repair your active directory database.

Back

Leave a Comment