Chapter 1 Managing The Active Directory

Chapter 1: Monitoring Active Directory Page 1
Chapter 1: Managing Active Directory

Directory services have been around for a while, and every company has at least one, and in
many cases several, directories of information. Traditional directory services were based on the
X.500 standard for a hierarchical, extensible data store. However, many other types of directories
can be found in companies today that dont fit the X.500 model. Typical examples of directories
within companies include Enterprise Resource Planning (ERP) applications (produced by
vendors such as PeopleSoft, SAP, and Baan), network operating system directories (such as
Novells NDS and NT 4.0s Security Account Manager, or SAM, database), white pages
applications, and potentially dozens of other repositories where people or resource information is
stored.

Tip: For an excellent general overview of directory services and their various
implementations, I recommend reading I mplementing Directory Services by
Archie Reed (McGraw-Hill; ISBN: 007134408X).
The first revision of Active Directory (AD) represents another instance of these multiple
directories that a company can implement, albeit with a slant towards managing a network
operating system. AD is an X.500-compliant implementation, which means it loosely follows
the constructs that the X.500 standard specifies but deviates as the needs of the vendor dictate.

Of course, Microsofts goal is for you, the customer, to use AD as more than just a network
operating system directory. Indeed, Microsoft Metadirectory Services (MMS), which is based on
the former ZoomIt! Metadirectory product, promises to tie AD, as well as all of your other
disparate directory services, into a common, Microsoft-centric directory namespace. The engine
behind the namespace will, in the future, most likely be based on AD.

AD is the most significant, and arguably the most important, change that Windows 2000 brings
to the NT product line. It replaces the NT 4.0 SAM database as a repository for domain security
principals like users and computers, but it does much more than that. AD introduces the concept
of an extensible, hierarchical directory service. And, whats perhaps most interesting, AD
provides the basis for what I think will be the emergence of many directory-enabled
applicationsthat is, applications that use the directory as a store and a source of information to
facilitate many types of value-added computing. Using Microsofts Active Directory Service
Interfaces (ADSI), a set of application programming interfaces (APIs) for accessing AD
information, independent software vendors (ISVs) will now have an easy and compelling path
towards directory-enabling their applications in many useful ways.
Page 2 Chapter 1: Monitoring Active Directory

For the system administrator, AD and ADSI provide many new capabilities for managing Win2K
users and devices. But they also open up a whole new level of complexity and a significantly
greater requirement for good planning before implementation. AD, in its first incarnation in
Win2K, also brings some interesting architectural and technical challenges that youll need to
take into consideration as you proceed in your planning. This chapter will give you the
information you need to become an AD expert. Ill describe the behind-the-scenes structure of
the directory and point out how you can leverage it. Ill also touch on some practical advice for
the systems administrator facing the daunting task of not only implementing, but also managing
and troubleshooting, an AD infrastructure.
AD Fundamentals
In order to implement and support an AD infrastructure, you need to have a lot of good
information about how the AD works at a high level. However, in order to troubleshoot and
optimize your AD implementation, you need to know how to do more than just navigate
Microsoft Management Console (MMC) snap-ins. You need to understand whats really going
on under the covers. You need to be part developer, part system administrator and part network
engineer. Based on that, I thought it would be valuable to give you some good technical detail
around how AD is structured and how it actually works. This next section is devoted to that task;
it forms the basis for later parts of this chapter as well as other chapters in this book.
The Schema
The kinds of things that can be contained within a directory servicethat is, the objects and the
properties associated with those objectsare defined in the directory schema. Just as with
databases, the schema defines the structure, if you will, of the directory service. . The AD
schema defines the types of objects and properties that you can create.

AD uses an object-oriented approach to defining directory objects. That is, there is a hierarchy of
classes, which define the kinds of objects that can be created within the directory. Each class has
a set of attributes that define the properties associated with that class. For example, AD has a
user class that has attributes such as firstName, Address, and so on. Interestingly, the AD
schema itself is stored in the directory as objects. That is, AD classes are stored as objects of the
class classSchema, and attributes are stored as objects of class attributeSchema. The schema,
then, is just a number of instances of the classes classSchema and attributeSchema, with
properties that describe the relationship between all classes in the AD schema.

To better understand this relationship, lets go back to the object-oriented model, upon which the
AD schema is based. Just as with object-oriented development languages, a class is defined as a
kind of basic definition of an object. When I instantiate an object of a certain class, I create an
implementation of that class. That implementation has a number of attributes, or properties,
associated with the class from which it was created. For example, suppose I create a class called
car, which has attributes like color, numberOfDoors, and so on. I can instantiate the class car
and create a real object called Ford Pinto with attribute values like white (for the color
attribute) and two (for the number of doors).

Similarly, an AD implementation within your enterprise is just the instantiation of the AD
schema classes and attributes into hundreds or thousands of different object classes and their
associated attributes. For example, I create an object of the class user called John Smith, who
has properties like password, address, homeDirectoryLocation, and so on. You can view the
AD schema using the MMC AD Schema snap-in.

The MMC AD Schema snap-in isnt a raw view of the AD schema. Rather, it provides a
sanitized view of the schema, shielding all of the individual attributes of every class and
attribute type of object. It basically shows the important info you need when viewing the schema.
To get a more raw look at all of the individual attributes for all of the classSchema and
classAttribute type objects in the AD, you can use the MMC ADSIEdit snap-in that I describe
later in this chapter in Naming Contexts. Figure 1.1 shows a view of the AD schema using the
MMC snap-in.

Figure 1.1: Viewing the AD schema using the MMC snap-in.
Classes
On the left pane in Figure 1.1 are two foldersone for classes and one for attributes. If you drill
into each folder, you see all of the AD classes and attributes defined in the default AD schema on
the right-hand pane. The default AD schema, when you load Win2K out of the box, contains 142
different classes and 863 different attributes. There are actually three different categories of
classes within the AD. These are described here:

StructuralA structural class is one that can be instantiated into a directory
object. All structural classes in the AD inherit from abstract or auxiliary classes.
AuxiliaryAuxiliary classes are used to extend the properties of a class that
inherits from it. However, you cant instantiate a directory object directly from
an auxiliary class, only from a structural class that has inherited properties from
the auxiliary class. There are actually two types of auxiliary classes. System
auxiliary classes are defined by the AD and therefore cant be removed. In the
second type, you as administrator of the AD can define auxiliary classes by
modifying the schema (described later in this section).
AbstractIn object-oriented (OO) parlance, the abstract class is similar to the
abstract base class in OO programming. That is, abstract classes are meant to be
parent classes of structural classes, but you cant instantiate a directory object of
an abstract class.

Figure 1.2 illustrates the basic relationship between these three types of classes and a typical AD
object.

Figure 1.2: The relationship between different AD schema class types.
If you look at Figure 1.1 again, you can see that under the highlighted classes folder, each class
type is listed in the right-hand pane as structural, abstract or auxiliary. The default AD schema

actually specifies only four system auxiliary classes, namely mailRecipient, samDomain,
samDomainBase, and securityPrincipal.

Note: The AD schema further categorizes classes into two types. Youll see
references to Category 1 and Category 2 classes. Category 1 classes are those
defined by Microsoft in the base product and are subject to certain
restrictions when you try to extend the AD schema (see Extending the
Schema below). Category 2 classes are those that you define and arent
subject to the same restrictions as Category 1 classes. You can identify the
category of a class by looking at its systemFlags attribute. If this attribute is
set to hex 10 (decimal 16), its a Category 1 class and is subject to
restrictions. Note that attributes are also categorized using this method.
In addition to containing these three types of classes, the AD schema is further described by the
relationship between specific classes. There is a hierarchy of inheritance within the schema that
defines which classes inherit from which others. At the top of the hierarchy is a class called top,
which is the mother of all classes, so to speak.

The convention of top as the root class comes from the X.500 specification and is used by the
AD as well. Each AD class defined in the schema has an attribute called subclassof, which tells
you what that classs immediate parent class is. For example, the classSchema object called
Person has a subclassof attribute of top. The classSchema object of class user has a subclassof
attribute of organizationalPerson, which is typically part of any X.500 implementation. A
subclass inherits those attributes defined for the parent class. For example, if the class
organizationalPerson contains an attribute for the address to a users Web page, objects of class
user will, by virtue of inheritance, also have that attribute.

In addition to having a parent-child relationship, AD classes also have a relationship to other
classes called possible superior. A possible superior is a class that can contain an instance of the
current class. For example, an object of type user class can be created within a domain or an
Organizational Unit (OU). However, it doesnt make sense to be able to create a user object
within a Group Policy Object (GPO). Therefore, GPOs arent a possible superior to the user
class.

There are actually two attributes on a class object that control its possible superiors. There is the
systemPossibleSuperior and the possibleSuperior attributes on every AD class. The
systemPossibleSuperior attribute is defined by Microsoft in the default schema and controls
what classes can contain instances of other classes. As the administrator of a forest (and by virtue
of membership in the Schema Admins user group), you can modify the possibleSuperior
attribute to specify additional possible superiors to a given class. Figure 1.3 shows this
relationship for the user class, viewed using the MMC AD Schema snap-in.

Figure 1.3: Viewing the PossibleSuperior Relationships for the user class object.
Also in Figure 1.3, you see any auxiliary classes that may be defined for this class. Think of
auxiliary classes as additional parent objects. They let you tack on additional attributes to a
particular class without changing the parent class. For example, suppose you wanted to add a few
attributes to user objects in your companys AD implementation that are specific to your
companyfor example, employeeID and shoeSize. You could extend the default AD schema to
create a new auxiliary class called myCompanyUser with these two new attributes, and make it
auxiliary to the user class, by adding it to the user classs auxiliaryClass attribute. Just as with
possible superiors, each AD class object contains two attributes related to auxiliary class
namely, systemAuxiliaryClass and auxiliaryClass. The former is defined by Microsoft for that
class, and you can modify the latter to add additional auxiliary classes.

Note: The behavior of class inheritance in the AD means that a given class
may contain a number of inherited attributes that have no relevance to its
function in the directory. This is normal, but it may be confusing to the
administrator who is looking through the schema. Generally, these unused
attributes arent exposed through the normal MMC administrative snap-ins
and dont cause a problem. However, you need to be aware of them in any
case.

Attributes
Ive discussed AD classes, and now Ill move on to discuss AD attributes. Attributes are defined
in the schema as objects of type attributeSchema. Every available attribute is represented in the
base AD schema. Attribute objects have a few interesting attributes themselves, namely syntax
and whether theyre indexed. Syntax indicates the type of data that the particular attribute can
store. For example, the surname (last name) attribute takes syntax of Unicode string,
indicating that the data in this attribute must be a string. However, an attribute like
userPassword, as you can imagine, needs to store information in a different form and thus has a
syntax of Octet string, indicating that the attribute can store binary data (see Figure 1.4
below).

Figure 1.4: Viewing the syntax of the userPassword attribute.
The AD supports a total of 23 different types of syntax for different data types, including basic
strings, dates, directory-related types of data like the so-called distinguished name and even a
syntax for Security Identifiers (SIDs).

In addition to supporting syntax, AD supports indexing attributes. Just as with a typical database,
indexing a particular attribute speeds any searches that you need to perform based on that
attribute. So, for example, if you need to do a lot of searches of your AD for user objects with the
same manager, you can modify the schema to index the manager attribute. This improves the
speed of that particular search operation within the directory.

Another property on schema attributes that you can set controls whether the attribute is replicated
to the Global Catalog (GC). I havent talked yet about the GC, but its a partial replica of all
objects and some of their attributes within an AD forest. The GC is replicated to designated
domain controllers (DCs) within your forest. The set of attributes that is replicated to the GC is
controlled in the schema. Objects of type attributeSchema have an attribute called
isMemberOfPartialAttributeSet. If this attribute is set to TRUE, that attribute is replicated to
the GC. You can enable this attribute using the AD Schema snap-in by right-clicking a particular
attribute, selecting Properties, then selecting the Replicate This Attribute to the Global Catalog
option (see Figure 1.5).

Figure 1.5: Choosing the option from the AD Schema snap-in to replicate an attribute to the GC.
Of course, attributes and classes dont exist in isolation from each other. Attributes are related to
classes in meaningful ways. As I mentioned above, classes inherit from each other through a
hierarchy of relationships. A parent class has a set of attributes associated with its object type.
For example, the organizationalPerson class has the streetAddress attribute associated with it.
And, by virtue of inheritance, the user class also has the streetAddress attribute.

Attributes come in two flavorsmandatory and optional. Mandatory and optional attributes for a
given class are defined in the schema for class objects using the following four attributes
systemMayContain, mayContain, systemMustContain, and mustContain. The two
mayContain attributes specify the optional attributes that the defined class may contain. The two
mustContain attributes specify the mandatory attributes for that class. Again, the two attributes

prefaced by the word system indicate that these are defined by Microsoft in the base AD schema
and cant be modified. When an attribute is mandatory for a given class, any object created from
that class must contain a value in that mandatory attribute at creation time. For example, the user
class has eight mandatory attributes that must be filled in when a new user object is created.
Figure 1.6 shows these mandatory attributes for the user class from the AD Schema snap-in.

Figure 1.6: Viewing the mandatory attributes for the user class.
Note that the far right column of the right-hand pane in Figure 1.6 lists the source class for that
particular attribute. That is, all of the mandatory attributes for objects of the user class are
inherited from parent or auxiliary classes. For example, the samAccountName attribute (which
stores a users downlevel NT 4.0-compatible user id) was inherited from an auxiliary class called
securityPrincipal. All eight of these mandatory attributes must have values when you add a new
user object to the AD; otherwise, the creation will fail.

Youll notice that, when you use the new user creation wizard available in the MMC AD Users
and Computers snap-in, youre asked to provide some basic information, including the users full
name, Win2K User Principal Name (UPN), and down-level logon name. Using this information,
and other information the wizard derives automatically, the eight mandatory attributes (as well as
a number of optional attributes) are filled in for the new user created by the wizard.


What is the User Principal Name (UPN)?
Youll see references in AD documentation to something called the User
Principal Name. When you create a new user object in the AD, you assign it a
Win2Kcompatible logon id. The new user also gets a downlevel NT 4.0style
logon id (to go with the AD domains downlevel name). The Win2K-
compatible logon takes the form of username@<dnsdomainname>.
For example, if I create a user account called John Smith in the AD domain
called mycompany.com, the UPN for that user might take the form of
jsmith@mycompany.com or john.smith@mycompany.com. Either one is a
valid UPN. When that user logs onto the domain from a Win2K workstation,
they can provide either their UPN or their down-level(such as
mycompany\jsmith) logon name. Note, however, that both the UPN and the
downlevel logon name must be unique within the domain. That is, you cant
have two jsmith@mycompany.com accounts, nor can you have two
mycompany\jsmith accounts.
The AD also gives you the ability to create something called Alternative UPN
Suffixes. These are alternate domain names that you can use when creating
your User Principal Names. You create Alternative UPN Suffixes from the
AD Domains and Trusts snap-in, by right-clicking the words Active
Directory Domains and Trusts, choosing properties and adding additional
UPN suffixes. UPN suffixes are forest-wide, and let you choose a different
domain name for your UPNs from the actual name of your AD domains. For
example, suppose you have a forest with two domains called east.myco.com
and west.myco.com, but you wish to have users in both domains login using a
UPN of user@myco.com. You can create a UPN suffix of myco.com, which
then can be assigned as the UPN domain name for users in both domains.
Note that the Alternate UPN suffix is merely an AD object, and has relevance
only for UPNs. It does not have a corresponding DNS domain within your
DNS infastructure.
Optional attributes are just thatoptional. What youll find is that each object class in the AD,
by virtue of inheritance, can contain a large array of attributes. For example, the user class
inherits some 73 attributes from the root class, top. Many of these attributes arent exposed
through the normal AD management snap-ins, and many of them are totally irrelevant to a user
object. However, they are there by virtue of inheritance and can be defined if needed.
Extending the Schema
One of the biggest advantages of the Win2K AD over the NT 4.0 SAM is that you can extend the
AD schema as your organizations needs dictate. While extending the schema shouldnt be taken
lightly, you can in any case add new attributes and classes to the base AD schema if application
or infrastructure needs arise. In addition, youre likely to find third- party software vendors
taking advantage of this extensibility by requiring new AD classes or attributes when you install

their applications in the future. There are some limitations on exactly how you can extend the
AD and some best practices on doing so that Ill describe in this section.

Lets first talk about what you cant do when youre getting ready to extend the base AD schema.
The following list spells out the restrictions in the current version of the product:
You cant add or remove any mandatory attributes from an existing class. So,
for example, the organizationalPerson class contains a mandatory attribute
called ntSecurityDescriptor, and this cant be removed. Nor can you add a new
mandatory attribute to this class. Note that this also means you cant add a new
mandatory attribute to an existing class by virtue of adding an auxiliary class to
an existing class. For example, if I tried to have the organizationalPerson class
inherit a mandatory attribute from an auxiliary class that I created, this wouldnt
be allowed.
Once you add a new class or attribute, you cant delete it from the AD schema.
You can only mark it defunct, which prevents any more instances of objects or
attributes of that class from being created, but doesnt remove existing objects.
Note that only Category 2 classes and attributes (those that you create yourself)
can be declared defunctCategory 1 classes and attributes are considered
system critical and cant be marked defunct. Also note that if you mark an
attribute defunct, any classes that contain that attribute (that is, have
mayContain or mustContain values that include the defunct attribute) must
also be declared defunct. This is because some of those classes might have the
defunct attribute declared mandatory, and that would prevent objects of that
class from being created.
There are limits on how Category 1 classes (those created by Microsoft and that
therefore may have system-critical roles) can be modified. Namely, you cant
rename a Category 1 class or attribute. You cant change the following attributes
of a Category 1 attribute: rangeUpper, rangeLower, or
attributeSecurityGUID. You cant change the defaultObjectCategory
attribute for a Category 1 class, nor can you change the objectCategory
attribute for an AD object created from a Category 1 class. Finally, you cant
change the lDAPDisplayName of a Category 1 class or attribute.

Once youve determined that these restrictions arent going to impact your planned schema
changes, the next step is to determine what kind of change you need to make. For example, are
you just looking to add some additional attributes to an existing class? Do you need a completely
new class that shares none of the attributes with any existing ones? Or do you want to create a
new subclass of an existing class, so that it inherits the features of that parent class, but add more
features of its own? These are the three scenarios youre likely to face when you think about
extending the schema.

To illustrate the process of extending the schema, Ill tackle the scenario where I want to add
new attributes to an existing class. To accomplish this, I have two options. I can either create a
new auxiliary class that contains the attributes Im interested in adding, or, I can add new

attributes to an existing class. The former approach is desirable if I need my new attributes to be
available to more than just one class. For example, I may want to use my auxiliary class to
extend user and group classes. Its more efficient to do this by creating a single auxiliary class
rather than duplicating new attributes on each individual class that I need to extend.
Obtaining OIDs
The first step I need to take to extend the schema (after I decide which method Im going to use
to do so), is to obtain a root X.500 Object Identifier (OID) for my new classes or attributes.
Every class and attribute in the AD is uniquely identified by its OID. Figure 1.7 shows the user
class with its OID highlighted.

Figure 1.7: Viewing the OID for the user class.
The OID naming scheme is part of the X.500 specification. As you can see from Figure 1.7, the
OID naming scheme uses a dotted notation that corresponds to the issuing authority (the vendor
or standards organization) for that schema element. If youre familiar with the SNMP protocol
and how MIB elements are identified, the directory OID scheme is a different part of the same
tree.

In the case of any X.500-based schema elements included in the AD schema, these classes and
attributes are identified using an OID that starts with the indication that it was issued by the
International Standards Organization (ISO), then follows a hierarchical tree down to vendor-
specific implementations. For example, if you look at the class top in the AD schema, its OID is
2.5.6.0. The first three numbers indicate the issuing authority, in this case the ISO. The last

number, 0, indicates that this class is at the root of this particular schema. If you look at some
other classes that are known to be part of the standard X.500 schema, like
organizationalPerson, youll see that they all start with 2.5.6, and the last number is
incremented. Likewise, if you look at schema elements created by Microsoftfor example, the
user class, its OID is 1.2.840.113556.1.5.9. All Microsoft schema elements begin with
1.2.840.113556.

If you need to modify the default AD schema with your own custom classes or attributes, youre
going to need your own root OID. Ideally, if you plan to make frequent and significant changes
to your AD schema, and especially if you plan to make your AD implementation available on the
Internet, register your organization to get an official ISO root OID with the governing body that
controls such things. In the United States, the governing body for OIDs is the American National
Standards Institute (ANSI) at http://www.ansi.org. If youre not in the US, you can go to the
ISOs Web site at http://www.iso.ch to find your own local governing body. Getting your own
registered OID ensures that any schema modifications you make dont conflict with those made
by another company.

If you dont plan to run your AD on a public network, and just intend it to be used within your
own organization for its entire life, you can use a Microsoft Resource Kit utility. Called
OIDGEN, it generates a unique OID underneath the Microsoft registered namespace (that is,
1.2.840.113556). OIDGEN is a command-prompt utility that takes no arguments and simply
returns a unique root ID for both class and attributes schema changes that you may want to make.
Figure 1.8 shows sample output for OIDGEN.

Figure 1.8: Viewing the output from the OIDGEN utility.
Two OIDs are listed hereone for new classes and one for new attributes. When youre ready to
add new classes or attributes, you can use these OIDGEN -generated OIDs at the root, then

simply tack on an incremented numeric value. For example, in Figure 1.8, the root OID
generated for new classes is:

1.2.840.113556.1.5.7000.111.28688.28684.8.471331.1747093.1818370.639263.

By adding the numeral 1 to the end of that:

1.2.840.113556.1.5.7000.111.28688.28684.8.471331.1747093.1818370.639263.1

you obtain the OID for the first class you plan to create.

To illustrate the process of extending the schema, create a new auxiliary class that adds some
new attributes to the user class. First, you need to make schema changes at the server in your
forest that has the Schema Floating Single Master Operation (FSMO) role. Additionally, the user
account that you use to log on to the Schema FSMO role-holder server must be a member of the
Universal Group called Schema Admins. You can extend the schema either using the MMC AD
Schema snap-in or programmatically using ADSI. Next, you need to add a registry value to the
Schema FSMO role-holder to enable schema modifications. In the following key:

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

you need to add a value of type REG_DWORD called SchemaUpdateAllowed and set it to 1.
Note that after making this modification, you need to restart the server for the Schema FSO role-
holder to take effect.

For the purposes of this example, Ill describe extending the schema using the MMC snap-in.
Lets say youre going to create an auxiliary class called myCompany-User, which will contain
the two attributes shoeSize and IQ. Youll then associate this new auxiliary class to the user
class. The first step is to create the two new attributes. From the AD Schema, right-click the
Attributes folder, then choose Create Attribute. Youre presented with a warning that creating
schema objects is a permanent, non-reversible process. Choose Continue to proceed with
creating the attribute. Youre presented with a dialog similar to the one in Figure 1.9.

Figure 1.9: Creating an attribute using the AD Schema snap-in.
The first fieldCommon Name, or cnindicates the object name for the new attribute within
the AD. For example, when youre describing an object relative to its position in your AD forest,
you use the cn, in conjunction with the location where that object resides, to name the object
the so-called distinguished name. For example:

cn=joe smith,OU=finance,DC=mycompany,DC=com

The cn can be called anything, but because youre creating a new schema object, you might want
to use a convention that makes it easy to identify the new schema object as your own. In Figure
1.9, I call the new attribute myCompany-ShoeSize to indicate that its a company-specific
attribute. The LDAP Display Name field is simply the name that LDAP (Lightweight Directory
Access Protocol) clients use to query your new class or attribute. In most cases, you can make
this the same as the common name.

Next, you need to provide the OIDeither the one that you registered with the registering body
for your country or the number you generated using the OIDGEN tool. In my case, I used
OIDGEN to generate a root OID, then added a .1 to the end to obtain my first attribute. (For my
second attribute, which Ill call myCompany-IQ, Ill add a .2 to the end of the same root OID.)

The next field required is the syntax. Remember from earlier in the chapter that the syntax
describes the type of data that the attribute can store. In the case of my shoeSize attribute, you
can choose to store it as a case insensitive string. This works well for something like shoe size,
but it may not work for other types of data. Finally, you can enter minimum and maximum
values for your attribute, which I entered here as 1-20. You can also check the box if this is to be

a multi-valued attribute. Multi-valued attributes (MVAs) are just what they implyattributes
that hold multiple values within a single instance. For example, Win2K stores members of a user
group as a single multi-valued attribute. Multi-valued attributes are discussed in more detail in
The Multi-Valued Attributes Conundrum later in this chapter.

Once youve created your first attribute, go ahead and create your second, IQ attribute, then we
can move on to creating the new auxiliary class. After creating your two attributes, you can go
back into the AD Schema snap-in and add a description for each attribute, choose to index it or
add it to the GC by right-clicking it and choosing Properties.

Note: Adding an attribute to the GC has implications for the amount of data
that is replicated to your forest-wide DCs, so its important not to make this
decision indiscriminately. GC data should be small in size, and change
infrequently, to minimize negative network impact.
Now that youve created your attributes, the next step is to create your auxiliary class, which
well call myCompany-User. From the classes folder in the AD Schema snap-in, right-click and
choose Create Class. Again, the common name and LDAP display name are going to be the
sameMycompany-User. And youll also enter a class OID similar to the attribute one (again
appending a 1 if this is the first new class using the assigned root OID).In the Parent Class field,
because this is an auxiliary class, Ill enter the top class because there are no particular classes
that you need to inherit from for this new one. Finally, select this class to be of type Auxiliary
(see Figure 1.10).

Figure 1.10:Creating a new auxiliary class in the AD schema.

When you click Next, youre presented with the screen that lets you associate your two new
attributes to this class as either mandatory or optional. Remember, however, that since we plan to
associate this new auxiliary class to the existing user class, youre restricted from making your
two new attributes mandatory. Figure 1.11 shows what the correct configuration will look like.

Figure 1.11: Adding optional attributes to a new auxiliary class.
Once youve associated the two optional attributes, the only schema modification steps that you
have to complete are to add your new auxiliary class to the user class and to reload the schema
cache so that your changes are immediately available. To associate your auxiliary class to the
user class, from the AD Schema snap-in, I highlight the user class from the left-hand pane,
right-click, then choose Properties from the context menu. Then, from the Properties window,
choose the Relationship tab. Here youll add your new auxiliary class to the auxiliary class list.
Figure 1.12 shows this operation.

Figure 1.12: Associating an auxiliary class with the user class.
Finally, in order for your schema changes to become available, you need to update the schema
cache. That is, the AD schema is cached in memory on a DC at system startup. Therefore,
changes to the schema wont reflect in new or existing AD objects until the schema is next
refreshed from disk. This normally happens five minutes after you apply the change, and of
course, it must replicate to all DCs throughout your forest (more on this later). If you wish to
force the change, you can do so from the AD Schema snap-in by highlighting Active Directory
Schema, right-clicking, then selecting Reload the Schema. After a short period of time, you
should see the new attributes available on new and existing user objects.

The final challenge is having the newly created attributes appear in one of the standard MMC
tools for administering AD objects. As youll notice, they dont appear automatically.
Unfortunately, unless you plan to manipulate AD objects using scripts or methods other than the
MMC, there is no quick and easy way to have your new attributes appear in, for example, the
AD Users and Computers snap-in.

While the full description of how to extend the MMC user interface (UI) is outside the scope of
this book, you basically need to build a COM-based Property page using a language like Visual
Basic or Visual C++, and then register that into an area of the AD configuration called display
specifiers. Ill talk a little bit about display specifiers later in this chapter, but if you want more
details about extending the MMC UI for AD administration, go to: http://msdn.microsoft.com
and search on Extending the User Interface for Directory Objects.

AD Naming Contexts
As you know, in Win2K as in NT 4.0, the domain is a boundary for AD objects like users and
computers. A single DC in the domain mycompany.com contains only objects that reside in
mycompany.com. On the surface, this is true. However, if you dig a little deeper, youll find that
there is actually more data on a given DC than just the objects from the domain to which the DC
belongs. In fact, every DC in a forest has at least three different partitions of data on it. These
directory partitions are also known as naming contexts. Each naming context (or NC) is
responsible for storing and replicating certain kinds of data. The three NCs are:
Domain
Schema
Configuration

The domain NC is, as its name implies, responsible for replicating domain objects to all DCs
within a single domain. The schema NC is responsible for replicating all schema objects, as I
described it above, to all DCs within a single forest. Finally, the configuration NC is responsible
for replicating data related to the site topology (including subnet objects), something called
display specifiers, which control how objects are displayed in the various user interfaces that can
display AD objects (for example, the MMC snap-in and the AD Find facility on the Start menu)
as well as other forest-wide metadata such as extended security rights for AD objects and well-
known built-in security principals like the Everyone and Authenticated Users groups. You can
view each of the three NCs using the MMC ADSI Edit snap-in that comes with the Win2K
Support Tools. Figure 1.13 shows the three NCs for my forest.


Figure 1.13:Viewing the three naming contexts using ADSI Edit.
In order to get this view, load the ADSI Edit snap-in, then connect to each NC separately. Right-
click ADSI Edit, select Connect To from the context menu, then choose the NC you wish to
connect to. Using this dialog box, you can also choose a specific server to bind with and (under
the Advanced tab) change the authentication id that youre using to connect to each NC. In
addition to the three NC, if a DC has been designated a GC server (see the discussion of the GC
later in this chapter), it will also contain the partial replicas of all other domain NCs in the forest.
These will appear as separate NCs on the DC. Figure 1.14 shows a graphical representation of
how NCs are replicated between DCs in a typical forest.

Figure 1.14:Graphical representation of the replication of the three naming contexts in an AD forest.
In this figure, you can see that the domain NC replicates only amongst DCs within that domain.
However, the schema and configuration NCs are replicated to every DC in the forest. Using the

Replication Monitor tool (Replmon.exe) from the Win2K Resource Kit, you can see each of the
NCs on a given DC, as well as view or trigger replication on each NC. When you start Replmon,
simply right-click Monitored Servers, select Add Monitored Server, then enter the server or
servers you wish to monitor. Replmon organizes servers by site, so you may see DCs from
several different domains within a site. Figure 1.15 shows an example of a monitored server
using Replmon.

Figure 1.15: Viewing a monitored server in the ReplMon utility.
As you can see in the figure, under the server A are the three NCsdomain (for
mycompany.com), schema, and configuration. If this server were part of a multi-domain forest
and it was designated as a GC server, you would see the GC partial replicas shown in ReplMon
as additional domain entries, like mycompany.com is shown. There is no additional designation
that ReplMon makes to indicate that a particular domain NC is really a GC partial replica.
The Physical AD
So far, Ive talked a lot about the logical portions of the ADthe schema and how attributes
relate to objects. Now Ill focus on the physical parts of it. Physically, the AD is backed by an
on-disk database. The actual database file is called ntds.dit, and, by default, its found in a
directory off the %systemroot% folder (for example, c:\winnt) called ntds. A pristine copy of
the base Win2K AD database is also stored in %systemroot%\system32\ntds.dit. This
copy is used when you DCPromo a member server to become a DC. The ntds.dit is a
transactional database file that uses Microsofts Extensible Storage Engine (ESE), also called Jet,

technology as the basis for the database. The ntds.dit file is actually composed of two main tables
that are used by the directory to store AD object data and four other system-related tables that
you dont normally encounter in Microsoft documentation.
The Data Table
The first table, called the data table, is responsible for keeping all objects and their attributes for
a given forest, as well as any indices that you define on a given attribute (remember that in the
discussion earlier on the schema, I mentioned that you could index an attribute for faster
searches). The format of the data table is pretty straightforward. All of the attributes available in
the AD schema are stored as columns in the data table (yep, all 863 of them). All objects that you
create within the AD are stored as rows. So, if you create a million objects in your AD forest, the
data table will have a million rows.

When you index an attribute for faster searching, that index is stored as part of the data table as
well. A base AD ntds.dit file, on the first DC in your forest, will have a data table that consists
solely of columns for the default attributes and rows for each of the classSchema and
classAttribute objects that define the AD schema. (Remember that the schema itself is
represented by regular AD objects of type classSchema and classAttribute.) As you add more
real objects, like users and computers, the number of rows in the data table grows. Note that, as
per our discussion in the previous section, all three NCs (domain, schema, and configuration) as
well as the GC partial replicas of all forest domains, are kept in the ntds.dit data table on each
DC in the forest (assuming that DC is a GC server as well).
The Link Table
The second table is called the link table, and it stores information that maintains logical links
between attributes on objects. That is, the link table tracks when you reference one AD object
from another. For example, an AD distribution list can contain user objects as members. Of
course, the list of members in a distribution list is stored in a multi-valued attribute in the
distribution list object. Additionally, the member objects themselves contain an attribute that lists
all distribution lists (and groups) that that object is a member of. Each relationship between the
members and members_of attributes for distribution lists and users, for example, is stored in the
link table.

The link table guarantees that when one link changes, the other is updated. (For example, when a
user is removed from membership on a dlist, the associated user attribute no longer lists the user
as being a member of the dlist.) The relationship between these two linked attributes is described
as forward links (the members of the dlist) and back links (the user object with the memberOf
attribute). The link table stores these forward-link and back-link pairs for each object in the AD
that contains such a relationship.
Where to Put AD Files
When you DCPromo a member server into a DC, youre given the choice of where you want to
store the ntds.dit file (the AD database), the SYSVOL volume, and the AD log files (explained in
the next section). The folder location you choose for each of these isnt terribly important. I

always like to use default folder paths because it makes it easier for others to find the files in
question. For best performance, especially as your AD database grows, its best to have several
physical disks in your DCs. In fact, the ideal configuration for an AD DC would be to have three
physical disks serving the following purpose:
One disk for OS system files and page files
One disk for the ntds.dit database file
One disk for AD log files

At a minimum, try to ensure that the system page file and AD log files are on separate disk
spindles; both typically see the largest disk activity when a DC is in production.
How Changes are Written to the AD Database
Microsoft has implemented a number of mechanisms to ensure that changes to the ntds.dit file
are successfully written and not easily corrupted by system crashes or hard disk problems.
Changes to the AD are transactional. That is, each discrete change is committed to the database
individually. For example, if I make a change to the password attribute on user Joe Smith, that
is a single, discrete transaction.

Similar to other Jet database implementations that Microsoft has carried out, the AD uses a
circular log to ensure that database transactions occur without a hitch. When a change is made to
the AD database, its first written to the copy of the AD thats running in memory on the DC
where the change was made. Its also written to a change log file stored on disk.

If you look in the directory where the ntds.dit file is stored on a given DC, youll see a number of
files in addition to the database file. For example, youll see three log files: edb.log, res1.log,
and res2.log. All of these log files are roughly 10MB in size. The edb.log file is the main log file
for the AD database. Res1.log and res2.log are set aside as reserves. If the disk partition where
these log files are stored runs out of disk space, these reserve log files ensure that there is enough
space on the disk to write any uncommitted transactions to the database before shutting down the
server.

Youll also find a file called edb.chk. This is the AD database transaction checkpoint file. The
transaction checkpoint file keeps track of the last transaction in the transaction logs that was
committed successfully to the ntds.dit file (this concept is illustrated in Figure 1.16).

Figure 1.16: The sequence that the AD uses to commit changes to the database.
The point of the edb.chk checkpoint file is to serve as a pointer to the location in the transaction
log fileedb.logwhere the last change was committed to ntds.dit. If an AD server were to
crash before all of the in-memory changes had been committed to ntds.dit, the checkpoint file
would allow a quick and easy replay of any transactions in the transaction log that hadnt been
committed before the crash. The checkpoint file isnt absolutely required for the AD to recover
itself after a crash. But recovering takes much longer because the system has to scan the entire
transaction log to determine which changes were already committed to the database file.

I mentioned previously that the AD uses a circular logging mechanism to track transactions into
the AD. This means that the edb.log file is a fixed 10MB in size. If more than 10MB worth of
transactions is created (which is likely over time), the newest transactions simply overwrite the
old ones. Unlike Microsoft Exchange, where you can disable the circular logging feature, Win2K
doesnt provide a way to do so. One log file is all you get!
Understanding and Managing AD Sites
Ive already alluded to AD sites in discussions above about the structure of the AD. Sites are an
important part of AD replication because you use sites, and site links, to manage which DCs
replicate with other DCs and how often. Sites also provide a boundary for defining Group Policy
(see Chapter 3 for more info on Group Policy). Finally, sites allow you to provide some location-
specific affinity for services that you wish to provide in the AD (for example, locating DFS
replicas, clients locating DCs, and so on).

Closely related to sites are subnet objects. Subnet objects are related to the topology of your
TCP/IP network. You define a subnet object for every TCP/IP segment on your network that will
have Win2K devices on it. Both site and subnet objects are stored in the configuration NC. This
makes sense because this kind of information needs to be available on every DC in your forest,
regardless of domain membership. When you first install a Win2K forest, a default site is created

for your first DCcalled Default-First-Site-Name. No subnet objects are created initially, but
you need to create them if you plan to gain any of the benefits provided by sites. When you
create a subnet object, you need to provide the IP address and mask of the subnet object youre
building, then associate it with a site that youve already built. All of this activity is done using
the MMC AD Sites and Services snap-in.

Note: By default, only Domain Admins on the forest root domain and
Enterprise Admins in the forest have rights to add and manage sites and
subnets. You can delegate these tasks to additional groups by modifying
security ACLs on the Sites folder within the MMC AD Sites and Services
snap-in.
To create a new site, start the MMC AD Sites and Services snap-in, right-click the Sites folder,
then choose New Site. Youll be prompted to provide a name for your new site and to associate it
with something called a site link. Youre not allowed to have spaces in your site name, so if you
want to create a site called New York, for all of your New Yorkbased Win2K resources, youll
need to call it something like New-York or NewYork.

If this is the first site youre creating in your AD forest, the only site link that will be available to
choose from is one called DefaultIPSiteLink. Site links are known as Inter-Site Transports. That
is, they help you group sites of similar network connectivity and let you control the inter-site
replication schedule between sites within a singe site link. Defining sites and site links is a
required part of building your AD infrastructure, and it will require careful planning and close
coordination and understanding of your organizations network topology.

Once youve started to create sites for your AD infrastructure, you need to add all of the IP
subnets associated with your corporate network where you plan to have Win2K devices, and you
need to associate those subnet objects with your sites. To create subnets, you right-click the
Subnets folder in the MMC AD Sites and Services snap-in. Figure 1.17 shows an example of
creating a subnet and associating that subnet object with a site called New-York.

Figure 1.17: Creating a Subnet object using the MMC AD Sites and Services snap-in.
If you go to the MMC AD Sites and Services snap-in after creating the subnet, youll see it listed
under the Subnets folder using the convention of IP Subnet/Mask (for example, 172.16.20.0/24),
where the mask is given in number of bits. In this case, 24 bits correspond to a mask of
255.255.255.0. By associating a subnet with this site, youre allowing any workstations or
servers that are on this IP subnet to be associated with the New-York site. This is called
establishing affinity between a workstation or server and an AD site.

Tip: You can determine the site that a workstation or server has associated
itself with by checking in the registry on that device for the value:
\HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
\DynamicSiteName
Alternatively, you can use the nltest.exe utility (part of the Win2K Support
Tools) and issue the following command:
nltest /server: <machinename> /dsgetsite

In addition to establishing site affinity, you can create location codes for each subnet that you
define. After defining the subnet, highlight it under the Subnets folder, right-click, select
Properties, then choose the Location tab. Here, you can use a new feature in Win2K-- the ADs
ability to keep track of a subnets physical location to help your users find printers more easily.
However, to use this feature, you must use a structured naming convention for the location

attribute within the subnet object, and you must enable a particular printer policy in Group
Policy. The Group Policy setting that must be enabled is under Computer
Configuration\Administrative Templates\Printers. The Pre-Populate Printer Search Location Text
item must be enabled.

For more information on Group Policy, see Chapter 3.
Additionally, the information you use in your location fields must be structured in a particular
way. For example, if subnet 172.16.20.0 is located in a building in New York, on 5th Avenue, on
the 20th floor, you would enter a location code for that subnet of NY/5thAve/20. Similarly, if you
have another subnet that spans two floors in the same building, you might enter it as
NY/5thAve/18-19.

Its important to delineate each geographic or spatial distinction with a slash character (/). The
AD uses this convention to determine the search hierarchy for locations. Using locations
correctly allows users to search for printers that are physically close to them and to consistently
choose the closest printer as they move around your network. Figure 1.18 shows what the Find
Printer dialog looks like when subnet location has been properly filled in for two locations
(Memphis and New York).

Figure 1.18: Searching for a printer by location.
Populating Subnet Objects
Unfortunately, Microsoft hasnt provided an easy, automated way for you to
create subnet objects within the AD. In a large enterprise, where you might

have hundreds or thousands of locations, you could have hundreds or
thousands of subnets within your IP address space. The ideal solution, if
youre a DHCP user, would be to use DHCP scope information to
automatically populate subnet objects. However, that capability doesnt yet
exist.
Your best bet at this point is to use a combination of tools and scripts to take
information out of DHCP and populate subnets. Win2K comes with a tool
called netsh.exe,which has the ability to dump all scopes from a DHCP
server. The sequence of commands is as follows:
netsh
netsh>dhcp
dhcp>server <IP address of your DHCP server>
dhcp server> show scope
The show scope command will dump all scope information for that server
to your screen. You can redirect the output to a file, then use that as the basis
for an input file to a script that creates new subnet objects based on each
scope.
Remember that site and subnet objects are kept in the configuration NC for
a given forest. Using that info, and some basic ADSI coding, you can create a
script that will import DHCP scopes, create new subnet objects, and
associate them with sites. However, this approach is best followed when
youre first populating your AD infrastructure with subnets. As you add new
DHCP scopes, youll still most likely need to manually create subnet objects.
DCs and Sites
As I mentioned, the first DC that you create in your forest will be automatically placed under the
Default-First-Site-Name site. Any subsequent DCs that you promote will also be placed in this
site unless you first build subnet objects and sites that encompass your new servers. If you need
to move a DC from one site to another, you can do this using the AD Sites and Services snap-in.
Under each site is a Servers folder. Within this folder are all of the DCs that are associated to this
site. You can move a DC to a different site simply by right-clicking on the server name, then
selecting Move from the context menu.

And while Im talking about DCs, I should explain what you see underneath each DC within its
site. Underneath each DC, youll see a container called NTDS Settings. This folder is where AD
replication connection objects are created. Connection objects are the mechanism by which
Win2K builds a replication topology between all DCs in your forest. Ill talk more about AD
replication in a later section of this chapter, but if youre interested in looking at what replication
connection objects have been created between DCs in your forest, this is the place to look.

Note: Normally, when you start up the MMC AD Sites and Services snap-in,
you see DCs (as opposed to member servers) listed only under the sites
youve created. This is expected because sites relate to replication topology;
only DCs replicate AD data. However, an interesting feature in Win2K
results in a situation where this may not be the case.
Some AD-enabled applications can also write information to the Servers
folder other than the replication-specific NTDS Settings folder. So, if you
DCPromo a DC back to a member server, youd expect the server to be
removed from the site to which it belonged. However, because its possible
that other application stuff may be written to this server object, Win2K
doesnt remove the server when its demoted. Rather, it just removes the
NTDS Settings folder and thus all of that servers replication connection
objects.
The main question that everyone asks when they start building their AD infrastructure is, What
constitutes a site? The answer is that there is no hard-and-fast answer. The typical scenario is that
you have two DCs within the same site, separated by a relatively slow-speed network link, and
you need to decide whether they should each be in their own site, rather than a single one. The
next question is, What is the threshold speed for that slow link before I create the second site?
My answer is always, When the amount of AD replication traffic traversing that link starts to
become the primary user of that links bandwidth, its probably time to split the two locations
into two sites to control the replication traffic moving between the two locations.

Microsofts AD Sizer Tool

Microsoft has a tool called AD Sizer (located on the companys website at
http://www.microsoft.com/WINDOWS2000/library/planning/activedirectory/
adsizer.asp) that can help you predict expected replication traffic on your
network for the size of AD forest youre using. Ill talk more about the issues
surrounding AD replication later in this chapter.
Understanding and Managing the Global Catalog
Ive already alluded to the global catalog (GC) in my discussion on naming contexts, but here Ill
drill into the GC and what it really is. To put it simply, in a multi-domain forest, Microsoft
needed a way for end users as well as Win2K services to quickly and easily find objects in the
AD without necessarily going to every domain in the forest to find them. Hence, Microsoft
created the GC.

The GC is a read-only partial replica of all objects, and some of their attributes, for all domains
in a forest. Its a partial replica because it doesnt include every attribute for every object in the
forest, and its read only because you can only search on it; you cant use it to modify objects in
the AD. The boundary of the GC is the forest; you cant have a GC that spans forests. As I

mentioned earlier, the copy of the GC on a so-designated DC is physically stored in the same
ntds.dit AD database file as the other NCs. I also mentioned that by modifying the schema, you
can add additional attributes to the GC that dont exist by default. However, you should note that
in Win2K today, if you modify the schema to add additional attributes to the GC, you force a full
re-synchronization of the GC across all GC servers in your forest.

Caution: Modifying the AD schema to change the attributes that are stored
in the GC will cause all GCs to perform a full synchronization, potentially
causing a large increase in network traffic.
The GC is particularly important when it comes to Universal Groups. As you know, Universal
Groups are groups whose membership can include (and is accessible to) users or groups in any
domain within a forest. Because of this cross-domain ability, all members of a given Universal
Group are included in the GC. This isnt the case for Global Groups or local groups (whose
membership isnt stored in the GC).

Because the GC is the only place where a client or server can go to get the complete membership
of a Universal Group from any domain, Microsoft made GC availability a requirement for a user
to be able to authenticate to an AD domain. This is because, at logon, a users access token is
built from a collection of their user SID and the SIDs of all groups the user belongs to. If the GC
werent available to provide the membership information for Universal Groups, the users token
would be incomplete, and any resources to which permissions had been assigned using that
Universal Group would be unavailable to that user.

So, if a GC isnt found by a client workstation when a user tries to log on, they are denied access.
The exception to this is where the domain youre authenticating to is in mixed mode, since
mixed-mode domains dont support Universal Groups, or if the authenticating user has cached
their credentials on the workstation due to a prior login. Additionally, if you are an administrator
on the domain, you dont need to have a GC present.

If youre in native mode and dont wish to deny logons if the user or computer cant find a GC,
you can change a registry value on the workstation or server in question. Specifically, in:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

you need to add a key called IgnoreGCFailures of type REG_DWORD with a value of 0x1.
Adding this registry value lets a normal user log on if a GC cant be contacted. However any
Universal Groups that the user (or machine) is a member of will also be unavailable because
when building the users (or machines) access token, their membership cant be resolved.
Deploying Global Catalog Servers
Because the GC is an important part of your Win2K infrastructure, how do you know how many
you need and where to deploy them? There are several answers to these questions. However,
lets take care of the basics first. How do you designate a DC as a GC? The easiest way to do this
is to start up the MMC AD Sites and Services snap-in and find the server that you wish to make a
GC server. Drill down to that servers NTDS Settings folder, right-click this folder, and youll

see a check box that says Global Catalog. Checking this box makes this DC a GC server. Its as
simple as that.

We already know that a GC needs to be highly available. This means that you generally want to
have a GC available on your network, near your users, at all times. Microsoft generically
recommends designating at least one DC as a GC in every AD site that you create on your
network. This means that, because of site affinity, client computers will always be able to find a
GC near them. However, youll need to balance this requirement with the additional overhead on
your network that is incurred by designating a DC as a GC server. And, in some large sites, you
may need more than one GC to handle the load.

Remember that a GC server contains, in addition to the three NCs (domain, schema, and
configuration), partial replicas of all other domains in your forest. If you have only one domain
in your forest, there really is no difference in the amount of data replicating to a GC server as
opposed to a normal DC. However, the more domains you have, the more data will be replicated
to a GC server. Because the GC data is a partial replica (includes all domain objects but only
some attributes) of all other domains, the amount of data replicated to a GC for each domain in
your forest is going to be smaller than the amount of data replicated by those DCs within each of
their own domains.

How much smaller? Well, tests have shown that about 20% less data is replicated to a GC for
each domains partial replica. Of course, this number will be impacted if you modify the schema
to include more than the base attributes that are replicated to the GC, but its a good guideline to
start with. So, for example, if you have four domains in your forest and each one typically
generates 1KB/second of replication traffic between DCs, a GC server could experience an
additional 3.2 KB/second of traffic (1KB/second per domain * 4 domains * 80%). Now, this
assumes that your domains are uniformly sending 1KB/second across the network. Most
domains wont experience this kind of constant network usage, nor will all intra-domain
replication traffic be replicated to a GC server (because the GC doesnt replicate all object
attributes).

The best approach to take for deploying GC servers is to first determine how many domains
youll have in your forest. Next, use a tool like the AD Sizer to determine how much traffic each
domain can be expected to generate. After that, you can estimate the impact that designating a
GC server will have on each sites network connectivity and on the rest of your corporate
network. Keep in mind the normal events that typically require access to the GC, which are listed
below:
If you log on using a User Principal Name. The GC is queried to determine
which domain your UPN resides in (especially if you use Alternate UPN
suffixes).
If you log on in a native mode domain. As I mentioned earlier, the GC is used to
determine Universal Group membership.
If you perform a search using one of the UI tools (for example, Start Menu,
Search, For People) whose scope is the entire AD.

Another distinction that needs to be made concerns the TCP ports that are used for searching the
AD. As you know, LDAP is the primary protocol used in many operations to communicate with
the AD. LDAP is used by ADSI and most MMC-based admin tools when manipulating the AD.
LDAP uses TCP port 389. However, if youre querying the AD programmatically or within an
application, and want to communicate with the GC instead, you need to use TCP port 3268. Port
3268 connects you directly to the GC, which of course has a forest-wide view of all AD objects.
Understanding and Managing AD Replication
Weve discussed the concept of sites and subnets as a means of controlling AD replication; now
lets take it one step further. In this section, Ill dive into the actual process that Win2K uses to
replicate AD data throughout your network. AD uses a replication approach that seeks to achieve
loose consistency with convergence between all DCs. This means that AD replication balances
the need for real-time updates across all servers with bandwidth constraints on your network. It
also means that, within a finite period of time, all DCs will be identical.

Explaining what you have to do to achieve this loose consistency with convergence is the goal
of this chapter. In an ideal world, all you have to do to build a good AD replication infrastructure
is to create sites and site links that fit your network topology, and Win2K does the rest. The basic
model for replication starts with the idea of Update Sequence Numbers (USNs). USNs are 64-bit
sequence numbers. Every object in the AD has a USN when its created. In addition, every DC
controls its own pool of USNs. The USN is key to how the AD stays consistent and resolves
conflicts. Additionally, replication happens at the attribute, rather than whole-object level. This
means that each individual attribute for a every object has its own USN as well.
USNs and Replication between DCs
The first thing to keep in mind is that each DC in a domain contains its own pool of USNs. The
USN, and some other information, is used to determine which updates need to take place as data
is replicated between DCs and, in the case of conflicts, which change wins.

Every time a change happens on a DC, the USN for the object or attribute is incremented.
Incrementing the USN on a particular DC occurs server-wide. That is, you cant have two
objects changing on a single DC with the same USN. If I change User As password on a DC,
and another administrator changes User Bs password, the USN on the password attribute for
User A would be 1711, and the USN for User B would be 1712. You can visually look at USN
information at the object level by right-clicking an object in the AD Users and Computers snap-
in, choosing Properties from the context menu, then selecting the Object tab (see Figure 1.19).

Figure 1.19: Viewing USN information on a User object.
In Figure 1.19, you see the USN assigned to the object when it was created (the Original USN)
and the most recent USN for the object (Current USN). The Current USN value indicates the
USN assigned to the attribute that was last changed on this object. When a new object is created,
the object and all of its attributes get the same starting USN number. Then, as each attribute on
that object is modified, its USN is incremented independently of other attributes for that object.
The AD Users and Computers snap-in doesnt expose the per-attribute USNs. instead, you have
to use a tool like repadmin.exe from the Win2K Support Tools. To view the per-attribute USNs
for an object, use the /showmeta option for repadmin and provide the DN to the object, as shown
here:

repadmin /showmeta "CN=Fred Smith,OU=Finance,DC=mycompany,DC=com"

The data that is returned is shown in Figure 1.20.

Figure 1.20: Viewing per-attribute USNs using the Repadmin utility.
To interpret the data in this figure correctly requires that I dig into how the AD uses USNs and
other information to replicate the correct data between DCs. First, lets look at the columns in
Figure 1.20. Note that there are two columns that contain the word USNthe Loc. (or local)
USN and the Orig. (or originating) USN. The local USN is the USN for that attribute that is
specific to the DC where that object is stored.

Remember that I mentioned that all DCs keep track of their own pool of USNs. This means that,
depending upon the number of changes made on a given DC, two DCs will likely be handing out
very different USNs. Win2K keeps track of this fact by differentiating between the local USN
(the USN for that object on a particular DC) and the originating USN. The originating USN is
the USN on an attribute that is replicated to its partners. When an object is first created on a DC,
the local USN and the originating USN are identical. However, as objects are replicated to other
DCs and are changed on those other DCs, the local USN will no long match the originating
USN. Ill dive into why this is in a minute.

But first, note that in Figure 1.20, the local and originating USNs are the same, even though
some changes have obviously been made to the attributes on this object. The reason for that is
that, in this particular AD environment, there is only one DC, and therefore, all changes are
happening on this DC. Also note that there are cases where more than one attribute has the same
USN. We know this is true when the object is created, but why is it that way after changes have
been made to individual attributes?


Its because the USN is incremented on a per-update transaction basis. For example, the figure
shows that five attributes have 2969 as their local and originating USN. This means that user
object Fred Smith was sitting with its current USN at 2968, and along came an administrator
and changed something (in this case, the password). This triggered the USN to be incremented
by 1 on five attributes (e.g. attributes dBCSpwd, unicodePwd, ntPwdHistory, pwdLastSet,
supplementalCredentials) that were changed in association with the password change operation.

Now, lets look at some of the other columns in Figure 1.20. The Originating DSA (Directory
Server Agent) is the site and name of the server that originated the last change on this attribute.
The Orig. Date/Time is the date and time stamp for the most recent change. The version number
corresponds to the number of times this attribute has been changed since it was created. All new
objects and their associated attributes start with a version of 1. Finally, the last column lists the
name of the attribute within the object.
Conflict Resolution
Using this basic information and some other metadata, a DC is able to replicate changes to its
partners in an organized way that maximizes convergence. Before I examine the actual
replication process, its important to understand how the AD deals with conflicts or collisions
where the same object or attribute is changed on multiple DCs.

Other directory services implementations use a mechanism whereby the time stamp on an
attribute is compared to other versions, then takes a last writer wins approach to resolving
conflicts. This approach requires pretty low tolerances on clock differences across all directory
servers in an environment. The AD doesnt use this mechanism. Rather, it uses a combination of
the metadata shown in Figure 1.20 to guarantee that the correct change happens in the correct
sequence across many DCs.

First, the USN is used to determine if a particular source DC has any new data for a destination.
If its determined that there is new data, a precession of the attribute version, then time stamp,
then originating DSA is used to act as a tiebreaker. For example, if DC A has a set of changed
attributes for Object X and DC B has a set of changed attributes, also for Object X, this
tiebreaker mechanism is used. For example, a DC C is replicating with DC A. DC C first looks at
DC As update version for a particular attribute or attributes. If its greater than the version
number that DC C has for that attribute on its local copy, the update is applied.

Now suppose DC B replicates its changes to DC C, and they request a change to the same
attribute using the same updated version number that DC B provided. In that case, the date/time
stamp is used to resolve the conflict. If DC Bs update to the attributed was made at a later time
than DC As, DC Bs update overwrites DC As. If not, the change that DC A provided stands.
In the unlikely event that both updates from both DCs have the same version and date/time
stamp (the resolution on the timestamp is 1 second), the Globally Unique ID (GUID) for the
originating DSA is arbitrarily used as the tiebreaker.

The Replication Process
Now that Ive presented some background on the replication process, the best way to describe
how the AD replicates directory changes between DCs is to walk through a typical scenario
modifying a user object on a DC and replicating the change to another DC. The easiest way to
illustrate this is to build a table that shows each of the key pieces of data that I described above
(for example, USN, version, and so on).

Lets assume that we have three DCs called ServerA, ServerB, and ServerC. ServerA contains a
user object that I just created called Bob Smith. Table 1.1 shows the basic replication metadata
for object Bob Smith. For simplicitys sake, Im going to show only a few attributes. Note that
all attributes on the object have the same USN and a version number of 1.

Object: Bob Smith
Local USN Orig. DSA Orig. USN Date/Timestamp Version Attribute
1000 ServerA 1000 01-01-
00,12:00PM
1 sn (surname)
1000 ServerA 1000 01-01-
00,12:00PM
1 givenName
1000 ServerA 1000 01-01-
00,12:00PM
1 profilePath
Table 1.1
The next step is to replicate this object to ServerB. The way this works varies depending upon
whether ServerA and ServerB are in the same site, but the bottom line is that ServerB is the
destination of ServerAs object Bob Smith. The first thing that ServerB does is communicate to
ServerA what its high-watermark USN is.

Each DC stores a high-watermark USN value for each of its direct replication partners. (Direct
refers to all DCs that have a direct connection object established with the DC.) In my example,
the high-watermark USN is the last USN that was replicated from ServerA to ServerB. ServerB
sends this information to ServerA to tell ServerA what it already has. This reduces any kind of
network usage and processor cycles that might otherwise have to happen between the two DCs if
they had to do a series of requests and replies to determine what was needed. You can view a
DCs current high-watermark USN for each of its replication partners by using the Support Tools
repadmin utility.

To get high-watermark information, type:

Repadmin /showreps /verbose

Under each DC listed in the output, you should see a line that says:

USNs: <high-watermark>/OU,...

The number that precedes the /OU tag is the high-watermark USN for that particular partner.

The second mechanism that the AD uses to prevent excessive replication traffic is called the Up-
to-dateness vector. The goal of this vector is to provide for propagation dampening. To explain
that, lets take the three servers in the example. Because a given DC can get replicated updates
from any number of replication partners, its possible that a change made on ServerA might be
replicated to ServerC first, then from ServerC to ServerB. This is more likely as the number of
DCs in a particular forest grows large because not every DC in every site will have a direct
connection to every other DC.

Therefore, the destination DC for a replicated event needs a way of knowing, for all possible
DCs on a given NC, what the last USN was for each DC. This is what the up-to-dateness vector
provides. If ServerA is replicating some attribute changes to ServerB, ServerB can look at the
entry for ServerA in its up-to-dateness vector table and see if its already received the last update
from any replica partner. If the vector is equal to or greater than the highest USN on ServerA, its
assumed that all changes are present. So, between the high-watermark and the up-to-dateness
vector, ServerB can tell ServerA exactly what it already has and exactly what it needs.

Note: You can check the up-to-dateness vector on a given DC by issuing the repadmin
/showvector <NC> command, where NC is the DN of the NC you wish to display.
(Remember that the up-to-dateness vector is specific to an NC.) For example, repadmin
/showvector dc=mycompany,dc=com provides the up-to-dateness vector for the domain NC
for mycompany.com.Lets continue with the example from Table 1.1. We replicate the object
Bob Smith from ServerA to ServerB, and Table 1.2 shows the resulting metadata, which is now
stored on ServerB.

Object: Bob Smith
2100 ServerA 1000 01-01-
00,12:00PM
1 sn (surname)
2100 ServerA 1000 01-01-
00,12:00PM
1 givenName
2100 ServerA 1000 01-01-
00,12:00PM
1 profilePath
Table 1.2
Note that in Table 1.2, all of the metadata related to the object Bob Smith remains the same
except for the local USN. The local USN is assigned based on the next USN that is available on
ServerB as a wholein this case, 2100. Now, lets suppose that an administrator changes the
profilePath attribute for Bob Smith on ServerB. Table 1-3 shows what happens to the replicated
metadata on Bob Smith after the change is made.

Object: Bob Smith
2100 ServerA 1000 01-01- 1 sn (surname)

00,12:00PM
2100 ServerA 1000 01-01-
00,12:00PM
1 givenName
2203 ServerB 2203 01-01-
00,17:35PM
2 profilePath
Table 1.3
In Table 1.3, you can see that a change was made to the profilePath attribute, resulting in it
getting all new metadata. It received both a new originating USN as well as a local USN. The
originating USN was changed because the attribute was changed on this server. The originating
DSA, version, and time stamp were updated as well. Now lets look at what happens during the
next replication cycle between ServerA and ServerB. ServerA sends its high-watermark USN
and up-to-dateness vector to ServerB, and ServerB sends the required records, namely the
changed profilePath attribute. Table 1.4 shows the resulting object on ServerA.

Object: Bob Smith
1000 ServerA 1000 01-01-
00,12:00PM
1 sn (surname)
1000 ServerA 1000 01-01-
00,12:00PM
1 givenName
1050 ServerB 2203 01-01-
00,17:35PM
2 profilePath
Table 1.4
Note that in Table 1.4, ServerA has placed its next available USN (1050) in the local USN field
for the profilePath attribute, but otherwise, the metadata stored in profilePath is as it was set on
ServerB.

Of course, this process becomes more complicated as you add more DCs, and more changed
objects per replication cycle, but the preceding tables help illustrate the process that Win2K goes
through to determine the correct change to apply to a DC during replication.
Understanding Replication Mechanics and the Role of the Knowledge
Consistency Checker (KCC)
Now that weve gone through the process by which the AD reconciles replicated data between
DCs, were ready to dive into the actual mechanics of replication and how sites and site links
impact replication. The process that is responsible for doing the heavy lifting of creating a
replication topology is called the Knowledge Consistency Checker (KCC).

The KCC is a process that runs on DCs within your forest. Every 15 minutes, it wakes up and
checks whether all DCs within and between sites are replicating with each other. If it finds
replication deficiencies, it builds connection objects between DCs within and between sites to
provide for a fully replicated environment. The KCC builds only inbound connection objects.

That is, given two DCs called A and B, the KCC running on A will create a connection object
only from B to A, and the KCC running on B will build a connection object only from A to B. In
essence, connection objects are only one-way.

You can see the connection objects built by the KCC from the MMC AD Sites and Services
snap-in. If you drill down into a site that youve created (or the Default-First-Site that the AD
creates when its installed), under each server in the site is an NTDS Settings folder. Within this
folder are the inbound connection objects between this server and other servers in your forest.
Connection objects are created for particular naming contexts. A single connection object will
replicate a single naming context.

You can tell several things about a connection object right off the bat. First, the name of the
connection object tells you one important thing. If the name is <automatically generated>, that
means that this connection object was built by the KCC, instead of being manually built by an
administrator. This is important because, if you start manually building connection objects, you
need to manually add or modify them as conditions within your AD infrastructure change.
However, if the KCC builds the connections, it will tear them down or add new ones as needed
each time it wakes up to assess your replication topology. You can get even more information by
right-clicking a connection object and choosing Properties from the context menu. Figure 1.21
shows an example of the Properties on a KCC-generated connection object.

Figure 1.21: Viewing the properties of a KCC-generated connection object.

In this figure, you can see that this connection object is coming from ServerA in a site called
SFO. In addition, the page shows the NC that is being replicated by this connection object
(Replicated Domain(s): mycompany.com) and, if this server is a GC server, youll see an entry in
the Partially Replicated Domains field. Also of note in this dialog box is the transport that this
connection object uses.

AD replication can use one of two transportseither synchronous Remote Procedure Call (RPC)
or asynchronous Simple Mail Transport Protocol (SMTP)to deliver replicated objects to its
destination. In most cases, RPC will be sufficient for well-connected, reliable networks.
However, if you have DCs located in far-off places using unreliable, or even dial-up links, you
may find that SMTP-based replication is the way to go. However, SMTP-based replication can
be used only for inter-site replication (between two sites) and only to replicate the schema and
configuration NCs and the GC. It cant be used to replicate any domain NC data, so it provides
limited value for most enterprise networks.

Youll also notice a Schedule button on the Connection Object Properties page. This option lets
you block out times of the day when you dont want replication to occur on a connection object.
For example, you may not want to have any replication occur to a server that is normally very
busy during regular business hours. You can block out that time in the schedule matrix and
prevent any replication on this connection object during that time.
Intra-Site versus Inter-Site Replication
The KCC builds connections objects for both -intra-site and inter-site replication. It uses a
typical spanning-tree algorithm to calculate a replication topology among all the DCs in a forest.
The process by which replication happens, however, varies depending on whether its intra-site
or inter-site.

Intra-site replicationreplication within a siteuses a mechanism call notify-pull replication.
That is, a source DC that has changes to replicate first notifies the destination that it has changes,
then the destination requests those changes from the source. Intra-site replication between DCs in
a single-site occurs by default every five minutes. If a DC detects that it has changes, it waits five
minutes before it sends those changes to replication partners (according to connection objects
that were generated by the KCC).

If you want to modify this five-minute window, you have to change a registry value on each DC
where you want the different behavior. The default interval is controlled by the following key:

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

This key contains a value called Replicator notify pause after modify (secs). This value takes a
number in hexadecimal format that represents the number of seconds before notifying a partner
for intra-site replication. (The default is 300 (hex12c), or 5 minutes.) Note that if you make this
number too small, you can decrease performance on your DCs; too large, and they may take a
very long time to reach convergence.


Inter-site replicationthat is, replication between sitesuses a different mechanism to trigger
events. Because inter-site replication is scheduled according to the site link to which the sites
belong, a destination DC will simply request any changes from a source DC across two sites at
the designated interval. This method is more efficient and better geared towards inter-site
connectivity.

Another aspect of intra-site replication that is noteworthy is the fact that when the KCC builds
connections objects between DCs, it does so in such a way that there will never be more than
three hops between any two DCs. A hop is the trip from one DC to another. As Figure 1.22
shows, this isnt an issue in sites with a small number of DCs (site A). But as the number of DCs
grows (site B), so do the required number of connection objects that the KCC must build in order
to keep the three-hop rule in effect.

Figure 1.22: Bigger sites require more connection objects to reduce hop count.
This issue doesnt arise with inter-site replication because replication between sites is handled by
a bridgehead server, which I describe later in this chapter.
Using Site Links and Site Link Bridges
Ive already touched briefly on site links earlier in this chapter (see Understanding and
Managing AD Sites), but now Ill dive into their role in replication. A site link is a set of sites
that replicate with each other on the same schedule and at the same cost. Site links are objects
that you create in the AD to group sites together, and theyre specific to a particular replication
transport (such as RPC or SMTP). Site links, as their name implies, are strictly related to inter-
site replication. Within a single site, they have no meaning.

Site links group sites by their network connectivity, and they have a number of properties that let
you control inter-site replication. Sites link objects are defined in the MMC AD Sites and
Services snap-in. If you drill down under the Sites folder to Inter-Site Transports, youll see two

folders called IP and SMTP, which represent the two available replication transports that you can
choose from. (Note that IP really means RPC.) If you drill down under the IP folder, youll see
defined site links for that transport.

By default, a new AD forest built from scratch will have one site link created for it called
DefaultIPSiteLink. Whenever you create a new site object, you have to join it to an existing
site link object or create a new site link object prior to creating the new site object. Its important
to realize that a site can and probably will belong to multiple site links. In fact, this is required
for site links to replicate with each other; more on this later. If you right-click a site link object in
the MMC snap-in, then choose Properties from the context menu, youll be presented with the
dialog box shown in Figure 1.23.

Figure 1.23: Viewing site link configuration options.
The interesting bits of information that are stored on this page are the member sites that are part
of this site link, the site link cost, and the frequency. Cost is an arbitrary number that you assign
to this site link to indicate the physical network bandwidth available between sites within this
site link. You need to assign a lower cost to high-speed connections like Metropolitan Area
Networks (MANs), which typically use a high-speed transport like ATM or SONET. And you
need to assign higher costs to site links that connect sites that use lower-speed WAN or dial-up
connections. Because cost affects an entire site-link, the goal is to group sites together that are
connected by similar bandwidth, be it low- or high-speed.

Frequency indicates how often replication occurs between sites within this site link. Frequency
can range from 15 minutes to 10080 minutes (168 hours). The idea here is that site links with a
lower cost (connected by high bandwidth) can handle more frequent replications than site links
with a higher cost.

The Schedule button controls when you allow replication to occur between sites within this site
link. When youre scheduling replication, keep in mind that the only path between two site links
may be through one or more DCs in a site that both links have in common. Suppose you set the
schedule on Site Link A to replicate only between 12:00 a.m. and 6:00 a.m. and on Site Link B
only between 6:00 a.m. and 12:00 a.m. Next, suppose that a site called NewYork is in both site
links. This means that, for that common site, there is no time when replication can occur from
one site link to the next. You simply need to make sure that the time in both sites overlaps so that
replication can flow between them.

Now that you understand the basics of how site links are configured, lets dive into how you
decide when to build a site link and what role site link bridges play. You need to have a good
understanding of your underlying network topology. Is your network composed of a series of
high-speed (that is, 10MB/second or greater) LAN or broadband links within a single
metropolitan area? Are you spread across a single country, with WAN links connecting regional
centers and branch offices? Or are you a multinational network with far-flung sites connected at
many different bit rates? Each of these scenarios will dictate how you configure sites and site
links for AD replication.

In addition, site links should be sensitive to things like speed and availability of network links.
Remember that a site link is a set of sites that will replicate with each other on the same schedule
and at the same cost. This means that all sites within a site link must be connected to each other
using network links of roughly equal bandwidth. In Figure 1.24, Ive sketched out a typical
corporate network containing three regional headquarters, each connected using high-speed
WAN links, and branch offices connected to each regional HQ.

Figure 1.24: Designing site links for a typical corporate network.
In this case, each regional HQ is a site, and the three sites are part of Site Link A. Each branch
office is a site, and each regional HQ branch office pair is part of the separate site links B, C, D,
and E. This is a typical hub-and-spoke site link configuration, where the site link connecting
each service center is the hub and each branch office site link the spoke. Youll notice that, from
a network perspective, each site within a given site link is an equal hop away from the other
site(s).

On each site link, I can assign a cost and replication frequency. The regional HQ site link will
have a relatively low cost and, most likely, a high replication frequency. On the other hand, the
branch office site links will have a higher cost (because their links are slower at 128KB/second),
and they may have a lower replication frequency. In this kind of configuration, to determine the
greatest amount of time it would take to replicate a change between two DCs, you can add up the
site link replication frequencies between all site links connecting a source and destination DC.

For example, if I needed to replicate a change between the branch office in Site Link E and the
branch office in Site Link B, I would add up the replication frequencies of Site Link E, Site Link
A (which I have to traverse to get to B), and Site Link B. This would represent the maximum
time it would take a change to replicate across the network. Using this approach, you can

calculate replication convergence within your AD infrastructure and make changes to your site
link schedules accordingly.

Implicit in this scenario is a feature that I havent talked about yet. In Figure 1.24, I talked about
Site A forming a hub to the branch office spokes. The feature that makes it possible for DCs in a
branch to replicate their changes across Site Link A to DCs in other branches is the transitivity of
site links. That is, if a branch office is a member of Site Link C and Site Link C shares a site in
common with Site Link A, which also shares a site in common with Site Link E, Site Link C can
replicate changes through Site Link A to Site Link E.

More precisely, transitive site links let the KCC build connection objects directly between Site
Link A and Site Link E. The transitive nature of site links happens automatically, but you can
disable it. (For examples of why you may want to disable this transitive behavior, see The AD:
What Works and What Doesnt later in this chapter.)) Go into the AD Sites and Services snap-
in, drill into Sites, Inter-Site Transports, and select either IP (RPC) or SMTP. Once youve
highlighted the transport, right-click it, choose Properties, then uncheck the Bridge All Site Links
option.

CAUTION: Do not disable site link bridging unless you know what youre
doing! Doing so can have an adverse effect on AD replication.
If you do need to disable transitive site links, you may need to build site link bridge objects to
bridge site links together. Site link bridges are needed when two or more site links connect sites
with no direct, end-to-end replication path. Site link bridging lets you pick a group of site links,
bridge them together, and allow transitive replication to occur for that group of site links.

In Figure 1.24, suppose I turn off site link bridging. Then, if I want the KCC to build a
connection object directly between a branch office DC in Site Link C and a branch office DC in
Site Link B, I add site links A,B, and C to a new site link bridge object. To create a site link
bridge manually, I go into the AD Sites and Services snap-in, then drill down into Inter-site
Transports.

You build a site link bridge for individual transports. So, if youre using both SMTP and IP
(RPC) as replication transports between a set of sites, youll need to make sure you build a site
link bridge that will cover all transports for a given set of site links. In this case, if you want to
build an IP-based site link bridge, right-click the IP folder under Inter-site Transports, then select
New Site Link Bridge from the context menu. Youll be prompted to enter a name for the site
link bridge and to choose which site links you want to include. Once youve built the site link
bridge, you should see its effects as the KCC builds new connection objects to allow for
transitive replication between the bridged links.
Inter-Site Topology Generators and Bridgehead Servers
Ive covered the details of intra-site and inter-site replication, but one area that I havent touched
on is using bridgehead servers in inter-site replication. Like MS-Exchange, Microsoft uses the
bridgehead server concept for inter-site replication. A bridgehead server is a designated DC that

is responsible for replicating AD changes between sites. So, if you have two sites, A and B, with
10 DCs in each, the KCC will pick one of those DCs in each site to be the bridgehead server for
that site. The KCC will then build connection objects between the bridgehead server in Site A
and the bridgehead server in Site B to facilitate replication between the two sites.

Its normally up to the KCC to choose a bridgehead server in the site, and it will do so without
any regard to server load or other characteristics that may effect the servers ability to be the
choke point for replication into and out of the site. However, the KCC will automatically choose
a new bridgehead server if the current one becomes unavailable. You, as the administrator, can
override the random nature of bridgehead election by selecting a particular server or servers as
preferred bridgehead servers. To do this, start the AD Sites and Services snap-in, drill into the
site of interest, then right-click the name of the server that you want to make preferred. Choose
Properties, and youll see the dialog box shown in Figure 1.25.

Figure 1.25: Making a server a preferred bridgehead for a site.
Choose the transport that you wish to make this server preferred for, then click Add. Note that
the moment you choose to designate a preferred bridgehead server, you turn off the KCCs
automatic selection process. If you designate only one preferred bridgehead server for a
particular site and that server is down, the KCC wont select another one, and replication will fail
between that site and others. To avoid this situation, its a good idea, if youre going to use
preferred servers, to choose two or even three servers as preferred. To let the KCC take over the

preferred bridgehead election process again, simply remove all preferred bridgehead servers
from the site.

There is actually another server role in each site that is responsible for creating the inbound
connection objects for the bridgehead server. The Inter-Site Topology Generator (ISTG) is
another KCC-designated role, and it takes responsibility for creating the connection objects
between its sites bridgehead server and all partner-site bridgeheads within its site link. By
default, the ISTG role is given to the first DC in a site. The ISTG role can be on the same server
as the bridgehead for a site, but it doesnt have to be.
Urgent Replication
Most changes to the AD respect normal intra-site and inter-site replication schedules. However,
there are a few events that can result in urgent replication. By urgent, I mean that as soon as a
change is made, its replicated to partner DCs within the same site. Earlier in this chapter, I
mentioned that intra-site replication happens using a notify-pull mechanism, which is different
than the scheduled process used during inter-site replication. For this reason, urgent replication
normally only happens intra-site because events that cause urgent replication to occur simply tell
the DC to immediately notify all of its replication partners. Because this notify process doesnt
have any effect on inter-site replication, even urgent replication events wont propagate between
sites immediately.

The three events that will trigger urgent intra-site replication are:
Account lockoutwhen a user account is locked out.
Changes to the Local Security Authority (LSA) database (such as account policy
changes).
A change to the server that holds the RID FSMO role.

Note: There actually is a way, for individual site links, to enable the
notification process to allow urgent (and even non-urgent) replication events
to happen inter-site on the same schedule as intra-site replication (that is,
within five minutes). You do this by changing an attribute on the site link
object in question. This change is detailed in the Win2K Resource Kit under
the topic Advanced Replication Management.
Manually Controlling Replication
You can trigger replication manually in several ways, overriding the intra-site or inter-site
schedules that the AD provides. The first and easiest way to do this is to use the MMC AD Sites
and Services snap-in. Drill down into a site, then into the desired server in the site, and finally
into the servers NTDS Settings folder.


You trigger replication by highlighting one of the servers connection objects with another
server. (Remember that connection objects are inbound from the server listed by the connection
object to the server youre focused on.) If you right-click the connection object, then choose
Replicate Now from the context menu, youll receive notification of the replication event. Note
that if you try to issue a Replicate Now command on a connection object connecting DCs in two
sites, youll receive a message indicating that the inter-site replication event cannot happen
immediately. This is consistent with the fact that inter-site replication isnt notification-based but
rather relies on a fixed schedule for that site link to control when replication occurs.

You can actually manually override this behavior (as well as trigger manual inter-site
replication) if you really need to force replication between sites by using either the graphical
ReplMon tool or the command-line repadmin tool from the Win2K Support Tools. Using
Replmon, highlight the NC you wish to replicate, right-click it, then choose Synchronize this
Directory Partition with All Servers, youll see a dialog box like that shown in Figure 1.26.

Figure 1.26: Viewing replication options in Replmon.
To force immediate replication to all partners of the chosen DC on the chosen NC, including
partners in other sites, choose the third check box, as shown in the figure. Youll be asked to
confirm whether you want to do this across site boundaries, and then the replication event will be
sent.
AD: What Works, What Doesnt
The title for this section sounds ominous, and its true that there are a few gotchas in what is
essentially a 1.0 version of AD. In most cases, however, youll be able to design around these
limitations. In other cases, you may find yourself in the position of waiting for Microsoft to fix
the issues before you can fully deploy AD.

The Multi-Valued Attribute Conundrum
This well-publicized limitation is the result of a design decision that Microsoft made in the AD
productnamely, that multi-valued attributes (attributes that contain multiple values, delimited
in some way) are replicated as one attribute. Remember that normally, the AD replicates at the
attribute level, so that if one attribute on an object changes, only that attribute is replicated to
other DCs. This is also true with multi-valued attributes but may not be desirable in some cases.
For example, security group membership is stored as a multi-valued attribute. If I create a global
group called Finance Admins, and it contains users Joe Smith, Jane Doe, and Bob Jones, each of
those three user ids is stored in a single attribute within the Finance Admins object.

What this means is that if you change one user membership on a group that has 200 members,
that whole 200-user-long MVA is replicated to every DC in a domain. This causes a couple of
problems. First, if two people are changing the membership of a group on two different DCs
(because of the loosely consistent approach that MS takes with AD replication, this is perfectly
acceptable), its possible that one of those changes could overwrite the other.

For example, suppose Sally, an administrator in Miami, changes my Finance Admins group to
remove Joe Smith (because Joe has been deleting users indiscriminately!). Sally makes the
change on a DC in Miami. Now, seconds or minutes later, before Sallys change has replicated to
the San Francisco DC, Fred, the San Francisco administrator, adds a new user named Rolf
Sorenson to the Finance Admins group. A short time later, Sallys change makes its way to San
Francisco, gets compared to Freds DC, and because its version number is the same as Freds
change, but its time stamp is older, Sallys change is ignored, and Freds change stands on the
San Francisco server.

Similarly, Freds change makes its way to Orlando, and because the version number for that
groups membership attribute is the same on both DCs, the time stamp is used to resolve the
conflict. In this case, Fred made his change after Sally, so Freds change is applied to the Miami
DC, and Sallys change is totally lost. Of course, this limitation can be overcome by using
administrative processes within your operations area that ensure that only a certain DC process
changes for certain AD groups. However, it can become cumbersome to use such a process.

The second problem with storing user group membership as an MVA is that there is a limit to the
number of users that can be stored in a groups membership attribute. Microsoft currently sets
this limit at around 5,000 members (although, curiously, there is no such limit on the Domain
Users group). The reason for the 5,000-member limit is that it otherwise becomes difficult to
reliably replicate such a large single attribute within a single AD replication transaction. If there
are more than 5,000 members in a group, the group membership list may never replicate
successfully. The solution to this problem is to use group nesting, which is available in forests
that have been converted to native mode. Again, the problem can be worked around, but it adds
administrative overhead.

Limitations on the Number of Sites
Another limitation in the AD to be aware of concerns the number of sites that you can configure
in a fully bridged site link environment. Currently, the KCC is limited in its ability to correctly
build connection objects for a site topology that exceeds around 200 sites. The exact formula that
Microsoft provides is:

(1 + number of domains in your forest) * Number of Sites ^2 must be less than or equal to
100,000

If this number isnt less than or equal to 100,000, the KCC cant calculate a replication topology
to provide a fully replicated AD infrastructure. The temporary solution to this problem is to turn
off transitive site links (as I showed earlier in the chapter) and enable site link bridges to
guarantee connectivity among all sites for all NCs.

Chapter 1 Managing The Active Directory

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Chapter 1 Managing The Active Directory

Încărcat de

Drepturi de autor:

Formate disponibile

Chapter 1: Monitoring Active Directory Page 1

Chapter 1: Managing Active Directory

S-ar putea să vă placă și