Windows administrators know that one of the most important aspects
involved with managing Active Directory is understanding the various
roles that servers need to play. Previously, I discussed the functions of the five flexible single-master operations (FSMO) roles in Active Directory.
Now I'm going to talk about the placement of those roles within the
forest and domain, and explain how to go about moving those roles to
other domain controllers, either by transferring them or seizing them.
Placing FSMO roles in the network
As I mentioned in the first article, the two forest-level roles—schema master and domain naming master—are installed by default on the first domain controller in the forest. The three domain-level roles—RID master, PDC emulator, and infrastructure master—are all installed by default in the first domain controller in the domain.
In a small office with one domain, it is very likely that all five roles are found on a single domain controller. But in a large enterprise network, you should not allow that to happen. It's best to make sure that the two forest-level roles are located in their own domain controller, with domain-level roles separate from them. If you choose to install the roles on more than one domain controller, those DCs should be replication partners.
At the same time, you can't ignore the domain controllers that host the global catalog. Remember that the domain-naming master must be on a DC hosting the global catalog. Not only that, but the infrastructure master must not be on a DC hosting the global catalog. (The only exception to that is if all the DCs are global catalog servers, which should not be the case in an enterprise network.) There are numerous ways you may decide to place your FSMO roles. Figure A shows one example.
Transferring roles
There are two basic reasons for moving an FSMO role from one DC to another. One reason is because you want to. That is, the movement is planned for some reason, such as decommissioning a server that holds one or more of the FSMO roles. When you are carrying out a planned move, it is called transferring the role.
The other reason to move a role is because you have to. For instance, you might be forced to move a role when a server that holds one or more FSMO roles has suffered catastrophic hardware failure. When you carry out an unplanned move, it is called seizing the role. You should never seize a role unless you absolutely have to.
Transferring a role can be done either through the graphic user interface (GUI) or through the command line interface (CLI), while seizing a role can only be carried out via the command line.
Whether done through the GUI or the CLI, moving a role is done in two steps:
Let's first look at transferring a role through the GUI. After that, I'll show you how it's done using the CLI.
Using the GUI
To change a domain-level role, click on Start | Administrative Tools | Active Directory Users And Computers. Next, as shown in Figure B, right-click on the domain and then select Connect To Domain Controller…
Next, you will see a dialog box in which you can specify to which DC you want to connect (see Figure C).
Once you have connected to the domain controller to which you will transfer a role, right-click once again on the domain and select "Operations Masters…" This will bring up the dialog box you see in Figure D.
This dialog box will allow you to transfer a domain-level role from one DC to another, provided that you have already connected to that DC. If you have not connected to the DC, the same name will appear in both boxes. To change a forest-level role, click on Start | Administrative Tools | Active Directory Domains and Trusts.
Next, as shown in Figure E, right-click on Domains and Trusts, and then select Connect To Domain Controller…
Once you have connected to the other DC, right-click once again on Active Directory Domains And Trusts, and select Operations Master… This will bring up a dialog box (see Figure F) similar to the one you used to transfer a domain-level role.
Using the command line interface
You can perform all of these same operations from the command line, using the Active Directory Diagnostic Tool, ntdsutil.exe. This tool is interactive, in that, when you invoke it, you have several submenus at your disposal. In this case, since I am talking about transferring and seizing roles, I will use the "Roles" submenu.
To do that, type "ntdsutil" at the command line. The prompt will then change to reflect the current level of the menu. In this case, at the "ntdsutil" prompt, you would type "roles." The command prompt will then change to FSMO Maintenance (as you'll see below in Figure G).
The commands available from the Roles submenu are:
Figure G illustrates using the tool to make a connection to another domain controller.
Figure H illustrates using ntdsutil to transfer a role.
Seizing a role
Transferring can only be done if the original DC is alive on the network. If a domain controller hosting a single operations master role is no longer available (possibly due to catastrophic failure), you will not be able to transfer that role to another domain controller. If that is the case, then you can move that role to another DC by seizing the role.
Seizing a role can only be done through the command line interface using ntdsutil.exe. It is extremely important to remember two things about seizing FSMO roles:
Take FSMO roles seriously
Networks using Active Directory still tend to be relatively young, so in all likelihood there has been very little need for administrators to concern themselves much with FSMO roles up until now. But as the network ages and it comes time for servers to be replaced, great care will need to be taken to preserve the integrity of those roles. At some point, domain controllers hosting FSMO roles will need to be replaced. Admins will need to understand where the roles are located and how to transfer the roles if an outage is planned, or how to seize a role if the outage is unplanned.
Original Post:
Placing FSMO roles in the network
As I mentioned in the first article, the two forest-level roles—schema master and domain naming master—are installed by default on the first domain controller in the forest. The three domain-level roles—RID master, PDC emulator, and infrastructure master—are all installed by default in the first domain controller in the domain.
In a small office with one domain, it is very likely that all five roles are found on a single domain controller. But in a large enterprise network, you should not allow that to happen. It's best to make sure that the two forest-level roles are located in their own domain controller, with domain-level roles separate from them. If you choose to install the roles on more than one domain controller, those DCs should be replication partners.
At the same time, you can't ignore the domain controllers that host the global catalog. Remember that the domain-naming master must be on a DC hosting the global catalog. Not only that, but the infrastructure master must not be on a DC hosting the global catalog. (The only exception to that is if all the DCs are global catalog servers, which should not be the case in an enterprise network.) There are numerous ways you may decide to place your FSMO roles. Figure A shows one example.
| Figure A |
 |
Transferring roles
There are two basic reasons for moving an FSMO role from one DC to another. One reason is because you want to. That is, the movement is planned for some reason, such as decommissioning a server that holds one or more of the FSMO roles. When you are carrying out a planned move, it is called transferring the role.
The other reason to move a role is because you have to. For instance, you might be forced to move a role when a server that holds one or more FSMO roles has suffered catastrophic hardware failure. When you carry out an unplanned move, it is called seizing the role. You should never seize a role unless you absolutely have to.
Transferring a role can be done either through the graphic user interface (GUI) or through the command line interface (CLI), while seizing a role can only be carried out via the command line.
Whether done through the GUI or the CLI, moving a role is done in two steps:
- Connect to a domain controller
- Transfer or seize the role
Let's first look at transferring a role through the GUI. After that, I'll show you how it's done using the CLI.
Using the GUI
To change a domain-level role, click on Start | Administrative Tools | Active Directory Users And Computers. Next, as shown in Figure B, right-click on the domain and then select Connect To Domain Controller…
| Figure B |
 |
Next, you will see a dialog box in which you can specify to which DC you want to connect (see Figure C).
| Figure C |
 |
Once you have connected to the domain controller to which you will transfer a role, right-click once again on the domain and select "Operations Masters…" This will bring up the dialog box you see in Figure D.
| Figure D |
 |
This dialog box will allow you to transfer a domain-level role from one DC to another, provided that you have already connected to that DC. If you have not connected to the DC, the same name will appear in both boxes. To change a forest-level role, click on Start | Administrative Tools | Active Directory Domains and Trusts.
Next, as shown in Figure E, right-click on Domains and Trusts, and then select Connect To Domain Controller…
| Figure E |
 |
Once you have connected to the other DC, right-click once again on Active Directory Domains And Trusts, and select Operations Master… This will bring up a dialog box (see Figure F) similar to the one you used to transfer a domain-level role.
| Figure F |
 |
Using the command line interface
You can perform all of these same operations from the command line, using the Active Directory Diagnostic Tool, ntdsutil.exe. This tool is interactive, in that, when you invoke it, you have several submenus at your disposal. In this case, since I am talking about transferring and seizing roles, I will use the "Roles" submenu.
To do that, type "ntdsutil" at the command line. The prompt will then change to reflect the current level of the menu. In this case, at the "ntdsutil" prompt, you would type "roles." The command prompt will then change to FSMO Maintenance (as you'll see below in Figure G).
The commands available from the Roles submenu are:
- Connections
- Seize domain naming master
- Seize infrastructure master
- Seize PDC
- Seize RID master
- Seize schema master
- Select operation target
- Transfer domain naming master
- Transfer infrastructure master
- Transfer PDC
- Transfer RID master
- Transfer schema master
Figure G illustrates using the tool to make a connection to another domain controller.
| Figure G |
 |
Figure H illustrates using ntdsutil to transfer a role.
| Figure H |
 |
Seizing a role
Transferring can only be done if the original DC is alive on the network. If a domain controller hosting a single operations master role is no longer available (possibly due to catastrophic failure), you will not be able to transfer that role to another domain controller. If that is the case, then you can move that role to another DC by seizing the role.
Seizing a role can only be done through the command line interface using ntdsutil.exe. It is extremely important to remember two things about seizing FSMO roles:
- Never seize a role unless it is your last resort. If a DC hosting a role is only going to be down temporarily, don't worry about it. Your network will survive a short time without it.
- If either the schema master, domain naming master, or RID master role is seized from a domain controller, that domain controller must never be allowed to come back online.
Take FSMO roles seriously
Networks using Active Directory still tend to be relatively young, so in all likelihood there has been very little need for administrators to concern themselves much with FSMO roles up until now. But as the network ages and it comes time for servers to be replaced, great care will need to be taken to preserve the integrity of those roles. At some point, domain controllers hosting FSMO roles will need to be replaced. Admins will need to understand where the roles are located and how to transfer the roles if an outage is planned, or how to seize a role if the outage is unplanned.
Original Post:
No comments:
Post a Comment