For all of its fanfare and cool functions, when you
take off all the pretty interfaces and controls, Active Directory (AD)
is at its core a database named NTDS.DIT.
It has a defining schema, a set of partitions, and tables much like any
other database. It shares the data contained within the database among a
series of authoritative and nonauthoritative servers called domain controllers (DCs) and read-only DCs,
respectively. The directory database relies on the physical hardware on
which it resides to maintain consistent performance. If the hardware
has significant limitations of speed, capacity, or other performance
aspects, those limitations will be inherited by the directory database.
In a like manner, if the physical hardware suffers failures, those
failures will be perpetuated through the directory database. This
section covers how to manage the directory database by managing the
hardware on which the database resides.
So, how exactly should you do this? Here's how many successful clients have done it:
Install the operating system on a mirrored partition.
Install the NTDS.DIT database on a RAID 5 volume.
Install the log files associated with AD on a separate mirrored partition.
This straightforward
implementation provides performance and fault tolerance to the operating
system, directory database, and log files by distributing the processor
and disk workload across multiple physical platforms. It does take a
fair number of disks to implement, but the resulting benefits in
performance and fault tolerance are well worth it.
What about other options
for installation? Couldn't you install the OS, directory database, and
log files on a single local drive? In short, yes, you could install them
all on the same physical drive. Please don't do this, though. It just
places too much of a workload on a single point of failure. When that
drive fails (and it will), you will lose everything. Bite the bullet up
front, and set up your directory for performance and fault tolerance.
Once your directory database is happily running on its physical
hardware, which you will be constantly monitoring to maintain its health
and performance, then it's time to start considering some important
topics.
1. Maintain FSMO Roles
Active Directory is stored
in writable form on multiple DCs. Usually having all these writable
copies of the directory database is just fine. On rare occasions, it can
be problematic having all of these DCs have write access, such as when
you are creating new domain objects, when you are changing the schema of
the directory, or when you are changing a user's password.
These are the FSMO (pronounced "fizz-mo") roles:
Schema master
The schema master domain controller controls all updates and
modifications to the schema. To update the schema of a forest, you must
have access to the schema master. This role would be used in conjunction
with the adprep or domainprep command. There can be only one schema master in the whole forest.
Domain naming master
The domain naming master domain controller controls the addition or
removal of domains in the forest. There can be only one domain naming
master in the whole forest.
Infrastructure master
The infrastructure master is responsible for updating references from
objects in its domain to objects in other domains. It is also used in
conjunction with adprep or domainprep
and to update SID attributes and distinguished name attributes for
objects that are referenced across domains. At any one time, there can
be only one domain controller acting as the infrastructure master in
each domain.
Relative ID (RID) master
The RID master is responsible for processing RID pool requests from all
domain controllers in a particular domain. These RID pools are used to
create new user accounts, computer accounts, or groups. At any one time,
there can be only one domain controller acting as the RID master in the
domain.
PDC emulator
The PDC emulator is a domain controller that advertises itself as the
primary domain controller (PDC) to workstations, member servers, and
domain controllers that are running earlier versions of Windows. It is
also the domain master browser, and it handles password discrepancies
and updates to user and computer account passwords. At any one time,
there can be only one domain controller acting as the PDC emulator
master in each domain.
The real questions begin when you start to consider that the initial DC that is built in each forest (referred to as the forest root server)
will by default hold all five FSMO roles. Should they stay there when
you add DCs? If not, how do you move them? What if, heaven forbid, the
server that holds your FSMO roles crashes and burns? What do you do
then?
On the day it is installed, the
forest root server does in fact hold all five FSMO roles, and while you
are setting up your other DCs, that forest root server will likely do
just fine holding all five roles. Remember that the roles come in two
types: forest-wide roles, one per forest, and domain-wide roles, one per
domain. Each forest will have a single schema master and domain naming
master regardless of the number of domains you create. These roles are
just fine to stay on your forest root server. Each domain will have its
own PDC emulator, RID master, and infrastructure master. As you create
new domains in your directory database and add new domain controllers to
manage those domain directory resources, the first DC created in each
domain will take on the domain-based roles for that individual domain.
This all proceeds quite nicely in an organized fashion as you build the
infrastructure of your directory. Assuming that you are allocating
sufficient server resources for each DC, you will not have any problems
with FSMO roles.
It is possible to relocate
the FSMO roles to another domain controller for reasons of personal
preference or in the event of a failure by a current role holder. The
circumstances surrounding the transfer of roles will determine the
process of the role change. If all the DCs are still online and you are
making a role change in a nice controlled environment, that's a role transfer.
If the server that holds the role is offline for any reason, such as it
has failed, you will take the role from it in a process called seizing the role.
Although the absence of an FSMO
role holder can have serious consequences, it is much more likely that
the failure of a FSMO role holder can be tolerated in most situations
for at least a limited amount of time, allowing you to "fix" whatever
caused the DC to fail.
2. Transfer FSMO Roles
Ideally, you will be doing a
nice planned transfer of roles from one operating DC to another. In this
case, you have a couple of options:
Use the
graphical user interface tools to view role ownership and initiate
transfers. The graphical tools can be used only if the server that is
the original role holder is still online. If the original role holder is
not currently online, then the transfer of roles (seizure) can be
performed using the command-line utilities only.
Use the command-line utility called NTDSUTIL to script the transfer or seizure of roles.
The GUI tools for viewing
and transferring FSMO roles include Active Directory Users And Computers
for working with the RID master, PDC emulator, and infrastructure
master.
Open the Active Directory Users And Computers tool.
Right-click Active Directory Users And Computers.
Choose Operations Masters.
You can click Change here to change the role to another server, as illustrated in Figure 1.
You must be connected to
the server that you want to change to. The GUI tool for viewing the
forest-wide tools is Active Directory Domains And Trusts for changing
the domain naming master.
Open the Active Directory Domains And Trusts tool.
Right-click Active Directory Domains And Trusts.
Choose Operations Master.
Figure 2 illustrates how you can view the role holder and change it to another computer.
The GUI tool for viewing
the schema master role is a little trickier. By default there is no
built-in or enabled GUI tool that you can use to work with the schema
master role. You need to both enable and add the Active Directory Schema
snap-in to the Microsoft Management Console (MMC) in order to have GUI
access to the schema master role. This tool is not enabled by default.
To enable the Active Directory Schema snap-in, follow these steps:
Type regsvr32 schmmgmt.dll, and hit Enter.
A message will appear confirming that DLLRegisterServer in schmmgmt.dll succeeded. Click OK.
You are not done yet. Now that you have enabled the tool, you will need to add it to the MMC in order to actually use it.
To add the Active Directory Schema snap-in to the Microsoft Management Console, follow these steps:
Select File 
Add/Remove Snap-In.
Select Active Directory Schema.
Right-click Active Directory Schema, and select Choose Operations Master.
Figure 3 shows how to view the schema master and change the server that hosts this role.
It is not always
possible to use the GUI tools to work with FSMO role changes. What if
the server you want to transfer a role from is offline? Connecting to an
offline server is not possible. You will have to take more drastic
action. As is often the case when working with Windows Server 2008 R2,
you can get significantly more options by using the command-line tool NTDSUTIL.
This utility will allow you to transfer FSMO roles and can also be used
to seize these roles without the express permission of the original
role holder.
NOTE
Once you have seized a role
from the original role holder, you will need to make certain that the
original role holder is not brought back online in that network.
2.1. Seize FSMO Roles with NTDSUTIL
To seize roles using NTDSUTIL, you can follow these steps:
Type ntdsutil in the Open text box, and then click OK.
Type roles, and then press Enter.
Type connections, and then press Enter.
Type connect to server servername, where servername is the name of the domain controller that you want to assign the FSMO role to, and then press Enter.
At the server connections prompt, type q, and then press Enter.
Type seize role, where role is the role that you want to seize. For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press Enter. For example, to seize the RID master role, type seize rid master. The one exception is for the PDC emulator role, whose syntax is seize pdc, not seize pdc emulator.
At the fsmo maintenance prompt, type q, and then press Enter to gain access to the ntdsutil prompt.
Type q, and then press Enter to quit the NTDSUTIL utility.
