Your education on AD begins with the components that deliver its services. This month: the store.
Active Directory by Design
Your education on AD begins with the components that deliver its services. This month: the store.
- By Michael Chacon
- June 01, 2000
Now that Windows 2000 is on the shelves and many machines
are coming pre-loaded, we’ll see a strong, continuous
push by Microsoft to induce businesses to move over to
the latest and greatest. Most prudent companies will take
small steps and continue to use the operating Windows
NT 4.x services. Essentially, the only thing that will
change is that the workstations and servers will be running
Win2K code. However, many of us will continue to use the
old supported NetBIOS-based services, at least until our
support staffs can get their arms around the new services
and architecture to determine if and how they want to
migrate to a complete Win2K environment.
While that issue works its way through your organization’s
pipeline, your best strategy to be ready for the big move
is to learn as much as you can before you’re called on
to take the slings and arrows.
Squarely at the center of the multitude of services available
in Win2K is Active Directory acting as the repository
for information. Recently, I’ve discussed directory services
in general; now I want to talk about AD specifically and
in detail. Obviously, AD is a complex and broad subject,
so this discussion will take place over the next several
I want to start with an overview of the components and
services that are combined to deliver AD services in the
context of the terms that have been standardized in X.500.
AD isn’t an X.500 directory, but it does follow the general
X.500 modular architecture. It’s useful to use X.500 terms
when discussing the various directory service components
as a reference point when you later compare specific competing
products to each other. This month I give an overview
of AD Directory System Agent (DSA) components or—as it’s
referred to in AD—the store.
single master operations
The AD Database
The underlying foundation of any directory, or any application
for that matter, is the database, which is referred to
in X.500 as the Data Information Base (DIB). AD refers
to the DIB as the store; it’s based upon the Exchange
JET storage engine. Microsoft is quick to point out that
it’s not the same JET engine that has been used in past
releases of Exchange (or Access, for that matter), but
a new version called the Extensible Store Engine (ESE),
which shares design with the JET engine, but not code.
The main characteristics of the database are that it’s
transaction-based, and it employs log and checkpoint files
to verify the transactions. Microsoft has claimed success
in tests with up to 1.5 million objects in the store.
The largest store I’ve heard about in a real organization
is just under 500,000 objects.
As you can imagine, backing up these files is critical
to the successful restoration of an AD. This process should
certainly be in the design documents. The backup process
becomes more complex as you add new domains. Remember,
each domain is only a partition of the directory store,
and at least one DC from each domain must be backed up.
The process is similar to the method for making sure that
a distributed Exchange messaging system is properly backed
up. I’ll cover this topic in more detail in a future column.
Unlike the SAM database, which was part of the registry,
the AD store is located in the NTDS.DIT file on a NTFS
partition on the domain controllers. AD’s distributed
store can be replicated on many different servers within
the same domain and also partitioned into many different
sections through different domains. Essentially, a domain
is a partition of the AD store. AD doesn’t support the
creation of DIB partitions smaller than the domain boundary.
Between the AD DSA and the DIB is the database layer,
which provides an access point into the actual ESE database.
In common Microsoft fashion, the database layer is an
abstraction layer between the data store, and applications
that are interested in the information in the store. This
layer can be accessed by the DSA or through other APIs
such as MAPI. It forms the Directory Information Tree
(DIT) structure for the DSA from the flat information
held in the directory store.
The DIB is the actual repository for the data that the
directory is comprised of. However, data isn’t useful
until it can be organized and accessed by interested agents,
such as applications and users. The real core of this
responsibility and of the directory itself is the Directory
System Agent. The DSA in AD terminology is a Domain Controller
(DC); it’s contained in the NTDSA.DLL that runs on DCs.
This DLL is installed and uninstalled with the dcpromo,
the Active Directory installation wizard, which finally
allows us to create and demote DCs without having to reinstall
the entire operating system (one of the great new features
of Win2K). The DSA Domain Controller is responsible for
providing updates to other DCs. These updates are organized
by type. The DSA is further broken down into several functions,
which are referred to as roles within the Domain Controller.
Although all DSAs working together are designed to provide
multi-master replication of attributes and objects within
the directory, some of the information in the DIB can’t
afford to have replication conflicts. Therefore, some
of the DSA functions are still single master-based. These
are called flexible single master operations (FSMO), and
Microsoft has defined five specific operations that rely
- Schema Master—The schema
is the actual structure of the DIB or store. This determines
where the attributes will be located in the database.
The schema for a given directory service must be consistent
throughout the entire forest. There can be only one
FSMO schema master within the entire forest of the directory.
- Relative ID Master—Each
domain uses this master to assign unique security IDs
to user, group, or computer objects. This FSMO is also
used when an object is moved from one domain to another,
to ensure that the RID remains unique across the forest.
- PDC Emulator Master—This
FSMO provides compatibility with the NT 4.x authentication
requests in a mixed-mode environment. This operation
is what allows AD to look just like a PDC to down-level
clients. It’s also used in a pure native mode environment
to resolve password inconsistencies. As with its NT
4.x virtual PDC counterpart, there can be only one PDC
Emulator Master in each Domain.
- Domain Naming Master—This
FSMO is responsible for managing the addition and deletion
of the domain names and controlling the uniqueness of
those names. If the administrator’s client machine can’t
connect to the DC assigned to this FSMO role, you won’t
be able to add or remove a domain. There’s only one
Domain Naming Master FSMO within a forest.
- Infrastructure Master—One
FSMO in each domain is responsible for enforcing group-to-user
references between domains as they’re updated in the
natural administration process. Microsoft advises that
if you have multiple DCs in a domain, don’t place a
Global Catalog on this machine, or the group-to-user
resolution process won’t work properly.
I know you’ve been hearing a lot about the multi-master
replication model for AD. However, as you can see, several
components still use the master/slave database model.
As you can imagine, this has a fundamental impact on where
you place these machines and on the type of machines you
use to support these services. You can’t count on multiple
instances of the FSMOs to create redundancies in the system.
These machines are best placed in locations that are physically
close (this side of routers) to the administrators who
are interested in them, and they also need to be closely
monitored for availability.
All FSMOs are determined automatically during the installation
process. However, as the network grows and the location
of these servers becomes less than optimal, you can transfer
these FSMO roles to other machines. Just make sure you’re
moving them to machines you’re confident will remain operational.
Treat them as you’d treat a PDC in NT 4.x.
These singular roles are normally transferred through
AD MMC snap-ins, but the roles can be seized from downed
machines if necessary. Again, this is similar to an NT
4.x BDC being promoted when a PDC fails. You seize these
roles with ntdsutil, a utility that comes with the Windows
2000 Resource Kit. That utility is also used for other
database management tasks such as moving, compacting,
repairing, and checking the integrity of the AD data store.
As with the BDC-to-PDC analogy, use caution when taking
this step. If the original FSMO comes back online, unpredictable
results can occur, and they won’t be pretty. If you have
an FSMO machine that goes down and you want to seize the
role for another machine, make sure you demote the original
DC component before bringing it back online. If you still
want it to be the FSMO for that role, then you need to
run dcpromo again to make it a DC and transfer the role
using the appropriate snap-in. This should remind you
of the reintroduction of a repaired PDC into a system
that has had a BDC promoted while the original PDC was
There are also generic roles that DCs play in AD that
are critical to the communication and synchronization
of the data store. Every DC automatically participates
in intra-site automatically through remote procedure calls
(RPCs). One DC within each site, defined as a group of
domain controllers within one or more subnets connected
with fast links, is configured as a bridgehead server.
These servers act as a replication focal point to other
islands of self-contained fast connectivity. Replication
is a topic I’ll cover in length in a future column.
The other major role DCs may play is in holding a copy
of the Global Catalog (GC). This is an assigned role,
and any number of DCs within a domain may hold a copy
of the GC. The placement of GCs is determined largely
by the characteristics of the physical network. The GC
is an index file that contains all of the objects in the
entire directory forest. This index information is stored
in the NTDS.DIT file along with the other directory information.
However, it doesn’t contain all of the attributes in the
forest, only the ones Microsoft has placed in there by
default. As the Administrator, you can add other attributes
if you want them included in the index.
The default base of attributes in the GC can’t be removed;
they’re used by services to find other services they need
to function properly. This index file also allows users
and applications to locate directory objects without any
knowledge of the domains and across a discontiguous namespace.
The DSA in a directory implementation is where most of
the work takes place to keep the system properly converged
and available to provide accurate and useful information
to requestors. Microsoft has taken the X.500 DSA model
and created a more modular implementation, using DCs as
DSAs. The most important thing to consider with this DC
model is that it isn’t a complete multi-master database
model. There are singular and relatively singular roles
that some DCs are chosen to play within the system. To
ensure operational availability, take care in where you
locate these physically and in the hardware you choose
to run them on.