Definitive Guide To Active Directory Troubleshooting and Auditing

(Sponsor Logo Here)
The Definitive Guide To

tm
The Definitive Guide To
tm
Active Directory
Troubleshooting
and Auditing

Don Jones
Introduction

i
Introduction to Realtimepublishers
by Sean Daily, Series Editor

The book you are about to enjoy represents an entirely new modality of publishing and a major
first in the industry. The founding concept behind Realtimepublishers.com is the idea of
providing readers with high-quality books about todays most critical technology topicsat no
cost to the reader. Although this feat may sound difficult to achieve, it is made possible through
the vision and generosity of a corporate sponsor who agrees to bear the books production
expenses and host the book on its Web site for the benefit of its Web site visitors.
It should be pointed out that the free nature of these publications does not in any way diminish
their quality. Without reservation, I can tell you that the book that youre now reading is the
equivalent of any similar printed book you might find at your local bookstorewith the notable
exception that it wont cost you $30 to $80. The Realtimepublishers publishing model also
provides other significant benefits. For example, the electronic nature of this book makes
activities such as chapter updates and additions or the release of a new edition possible in a far
shorter timeframe than is the case with conventional printed books. Because we publish our titles
in real-timethat is, as chapters are written or revised by the authoryou benefit from
receiving the information immediately rather than having to wait months or years to receive a
complete product.
Finally, Id like to note that our books are by no means paid advertisements for the sponsor.
Realtimepublishers is an independent publishing company and maintains, by written agreement
with the sponsor, 100 percent editorial control over the content of our titles. It is my opinion that
this system of content delivery not only is of immeasurable value to readers but also will hold a
significant place in the future of publishing.
As the founder of Realtimepublishers, my raison dtre is to create dream team projectsthat
is, to locate and work only with the industrys leading authors and sponsors, and publish books
that help readers do their everyday jobs. To that end, I encourage and welcome your feedback on
this or any other book in the Realtimepublishers.com series. If you would like to submit a
comment, question, or suggestion, please send an email to feedback@realtimepublishers.com,
leave feedback on our Web site at http://www.realtimepublishers.com, or call us at 800-509-
0532.
Thanks for reading, and enjoy!

Sean Daily
Founder & CTO
Realtimepublishers.com, Inc.
Table of Contents

ii
Introduction to Realtimepublishers.................................................................................................. i
Chapter 1: Introducing Active Directory.........................................................................................1
The Importance of Directories and Directory Management................................................3
Many Eggs, One Basket...........................................................................................3
New Tools for New Times.......................................................................................4
Meet AD...............................................................................................................................4
The AD Database.................................................................................................................6
Logical Architecture of AD.................................................................................................6
Objects and Attributes..............................................................................................6
The Schema..............................................................................................................7
LDAP.......................................................................................................................9
Domains, Trees, and Forests..................................................................................10
Organizational Units..............................................................................................14
The Global Catalog................................................................................................15
Physical Structure of AD...................................................................................................17
Domain Controllers................................................................................................17
Directory Replication.............................................................................................17
The Operations Masters.........................................................................................18
Sites........................................................................................................................19
ADs Backbone: DNS........................................................................................................20
Introduction to AD and Windows Monitoring...............................................................................21
AD, Win2K, and WS2K3 Monitoring Considerations......................................................24
Change Monitoring and Auditing......................................................................................26
Problem Resolution, Automation, and Alerting................................................................26
Other Considerations.........................................................................................................27
Summary........................................................................................................................................27
Chapter 2: Designing an Effective Active Directory.....................................................................28
ADs Logical and Physical Structures...........................................................................................28
Logical Structures..............................................................................................................29
Namespace.............................................................................................................29
Naming Context.....................................................................................................30
Physical Structures.............................................................................................................30
Designing AD................................................................................................................................31
Table of Contents

iii
Designing the Forest and Trees......................................................................................................31
Determining the Number of Forests..................................................................................34
Setting Up and Managing Multiple Forests...........................................................35
Determining the Number of Trees.....................................................................................36
Designing the Domains..................................................................................................................38
Determining the Number of Domains................................................................................39
Choosing a Forest Root Domain........................................................................................40
Using a Dedicated Root Domain...........................................................................41
Assigning a DNS Name to Each Domain..........................................................................43
Using an Internet-Registered Name for the Top-Level Domain...........................44
Using Internet Standard Characters.......................................................................44
Using Locations to Name Child Domains.............................................................45
Never Using the Same Name Twice......................................................................46
Dividing the Forest............................................................................................................46
Placing the Domain Controllers for Fault Tolerance.........................................................48
Determining Trust Relationships.......................................................................................48
Using Bi-Directional Transitive Trusts..................................................................48
Using One-Way Trusts..........................................................................................50
Using Cross-Link Trusts........................................................................................51
Designing OUs for Each Domain..................................................................................................53
Creating OUs to Delegate Administration.........................................................................54
Creating OUs to Reflect Your Companys Organization..................................................55
Creating OUs for Group Policy.........................................................................................56
Creating OUs to Restrict Access........................................................................................56
Designing the Sites for the Forest..................................................................................................56
Creating Sites and Site Links Based on Network Topology..............................................57
About Sites.............................................................................................................57
About Site Links....................................................................................................58
Creating the Site Topology....................................................................................59
Using Sites to Determine the Placement of Domain Controllers......................................60
Using Sites to Determine the Placement of DNS Servers.................................................61
Summary........................................................................................................................................61
Chapter 3: Monitoring and Tuning the Windows Server 2003 System and Network...................62
Table of Contents

iv
Monitoring WS2K3 Domain Controllers.......................................................................................62
Monitoring the Overall System......................................................................................................64
Using Task Manager..........................................................................................................66
Using the Performance Console.........................................................................................67
Event Viewer .....................................................................................................................69
Events Tracked in Event Logs...............................................................................69
Types of Event Logs..............................................................................................69
Starting Event Viewer............................................................................................70
Types of Events Logged by Event Viewer............................................................71
Sorting and Filtering Events..................................................................................71
Exporting Events....................................................................................................72
Monitoring Memory and Cache.....................................................................................................73
Using Task Manager to View Memory on a Domain Controller......................................75
Using the Performance Console to Monitor Memory on a Domain Controller ................76
Available Memory Counters..................................................................................77
Page-Fault Counters...............................................................................................78
Paging File Usage..................................................................................................79
System Cache.........................................................................................................80
Monitoring Processors and Threads...............................................................................................83
Using Process Viewer to Monitor Processes and Threads.................................................83
Using Task Manager to View Processes on a Domain Controller.....................................85
Working with the List of Processes.......................................................................87
Viewing Information About Processes..................................................................88
Using the Performance Console to View Processes on a Domain Controller...................88
% Processor Time Counter....................................................................................89
Interrupts/sec Counter............................................................................................90
Processor Queue Length Counter..........................................................................91
Monitoring the Disk.......................................................................................................................92
Using the Performance Console to Monitor the Disk Subsystem......................................92
% Disk Time and % Idle Time Counters...........................................................................92
Disk Reads/sec and Disk Writes/sec Counters..................................................................93
Current Disk Queue Length Counter.................................................................................94
% Free Space Counter........................................................................................................95
Table of Contents

v
Monitoring the Network................................................................................................................96
Using Task Manager to Watch Network Traffic...............................................................96
Using Network Monitor to Watch Network Traffic..........................................................97
Using the Performance Console to Monitor Network Components on a Domain
Controller...........................................................................................................................97
Domain Controller Network Throughput..............................................................97
Network Interface Throughput..............................................................................98
All That MonitoringSo Little Information.................................................................................99
Auditing as a Troubleshooting Tool ............................................................................................100
Planning for Auditing......................................................................................................100
Other Auditing Techniques..............................................................................................101
Summary......................................................................................................................................102
Chapter 4: Monitoring and Auditing Active Directory................................................................103
Using the Monitoring and Auditing Tools...................................................................................103
Third-Party Tools.............................................................................................................103
DirectoryAnalyzer................................................................................................104
ChangeAuditor for Active Directory...................................................................105
DirectoryTroubleshooter......................................................................................106
Insight for Active Directory.................................................................................107
AppManager Suite...............................................................................................108
Microsoft Operations Manager............................................................................109
Built-In Tools...................................................................................................................109
System Monitor....................................................................................................109
Event Viewer .......................................................................................................110
Replication Diagnostics.......................................................................................111
Monitoring the AD Infrastructure................................................................................................113
Monitoring the Domain Controllers.............................................................................................114
Using DirectoryAnalyzer.................................................................................................114
Using NT Directory Service Performance Counters.......................................................118
Monitoring the Domain Partitions...............................................................................................121
Using Domain Database Performance Counters..............................................................123
Installing the Counters.........................................................................................125
Monitoring the Global Catalog....................................................................................................125
Table of Contents

vi
Monitoring Operations Masters...................................................................................................127
Monitoring Replication................................................................................................................130
Using Directory Partition Replicas..................................................................................131
Schema Partition..................................................................................................131
Configuration Partition........................................................................................131
Domain Partition..................................................................................................131
Using Directory Updates..................................................................................................132
Using the Replication Topology......................................................................................133
Monitoring via Auditing..............................................................................................................138
Setting up Auditing..........................................................................................................138
Reviewing Auditing Messages........................................................................................139
Using ChangeAuditor for Active Directory.....................................................................140
Summary......................................................................................................................................142
Chapter 5: Troubleshooting Active Directory and Infrastructure Problems................................143
Following a Specific Troubleshooting Methodology..................................................................143
Troubleshooting Network Connectivity......................................................................................144
Testing for Network Connectivity...................................................................................144
Testing the IP Addresses..................................................................................................145
Testing the TCP/IP Connection.......................................................................................147
Performing Other Troubleshooting Tests Using DirectoryAnalyzer...............................148
Domain Controller Connectivity Test..................................................................148
Domain Connectivity Test...................................................................................149
Site Connectivity Test..........................................................................................150
Troubleshooting Name Resolution..............................................................................................152
Understanding Name Resolution.....................................................................................152
Checking that DNS Records Are Registered...................................................................152
Using Event Viewer.............................................................................................153
Using PING..........................................................................................................154
Using NSLOOKUP..............................................................................................154
Checking the Consistency and Properties of the DNS Server.........................................155
When the DNS Server Doesnt Resolve Names Correctly..............................................156
How the Caching DNS-Resolver Service Works................................................156
Table of Contents

vii
Using Other Techniques......................................................................................157
Troubleshooting the Domain Controllers....................................................................................158
Understanding the AD Database and Its Associated Files...............................................158
Comparing Directory Information...................................................................................159
First: What Changed?......................................................................................................160
Analyzing the State of the Domain Controllers...............................................................160
Using NTDSUTIL ...........................................................................................................162
Locating the Directory Database Files.................................................................163
Checking for Low-Level Database Corruption....................................................165
Checking for Inconsistencies in the Database Contents......................................166
Cleaning Up the Meta Data..................................................................................168
Moving the AD Database or Log Files................................................................171
Repairing the AD Database.................................................................................172
Troubleshooting Secure Channels and Trust Relationships............................................174
Troubleshooting the Operations Masters.....................................................................................175
When Operations Masters Fail.........................................................................................176
Schema Master.....................................................................................................176
Domain Naming Master.......................................................................................176
RID Master...........................................................................................................176
Infrastructure Master............................................................................................177
PDC Emulator......................................................................................................177
Determining the Operations Master Role Holders Locations..........................................177
Using the DSA and Schema MMC Snap-Ins.......................................................178
Using NTDSUTIL ...............................................................................................179
Using the Resource Kits Dumpfsmos.cmd.........................................................179
Using DCDIAG...................................................................................................179
Using AD Replication Monitor............................................................................180
Using Third-Party Utilities..................................................................................180
Seizing an Operations Master Role..................................................................................181
Checking for Inconsistencies Among Domain-Wide Operations Masters......................182
Troubleshooting the Replication Topology.................................................................................183
Viewing the Replication Partners for a Domain Controller.............................................183
Forcing Domain Controllers to Contact Replication Partners.............................184
Table of Contents

viii
Tracking Replicated Changes..............................................................................184
Forcing Replication Among Replication Partners...........................................................184
Viewing Low-Level AD Replication Status....................................................................185
Checking for KCC Replication Errors.............................................................................186
Troubleshooting by Using Change Management........................................................................187
Summary......................................................................................................................................188
Chapter 6: Creating an Active Directory Design that You Can Audit and Troubleshoot...........189
Design Goals................................................................................................................................189
Performance Considerations........................................................................................................190
Overauditing....................................................................................................................190
Overmonitoring................................................................................................................192
Design Considerations.................................................................................................................194
Who Will Troubleshoot?..................................................................................................194
How Will Auditing Be Utilized?.....................................................................................195
For How Long Will Data Be Maintained?.......................................................................197
Design Guidelines........................................................................................................................199
Selecting Appropriate Tools............................................................................................199
Configuring the Environment..........................................................................................201
Maintaining the Proper Configuration.............................................................................202
Monitoring Core Areas....................................................................................................202
Preventing Trouble.......................................................................................................................203
A Process for Change.......................................................................................................204
Tools to Manage Change.................................................................................................205
Summary......................................................................................................................................207

Copyright Statement

ix
Copyright Statement
2005 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that
have been created, developed, or commissioned by, and published with the permission
of, Realtimepublishers.com, Inc. (the Materials) and this site and any such Materials are
protected by international copyright and trademark laws.
THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web
site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be
held liable for technical or editorial errors or omissions contained in the Materials,
including without limitation, for any direct, indirect, incidental, special, exemplary or
consequential damages whatsoever resulting from the use of any information contained
in the Materials.
The Materials (including but not limited to the text, images, audio, and/or video) may not
be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
way, in whole or in part, except that one copy may be downloaded for your personal, non-
commercial use on a single computer. In connection with such use, you may not modify
or obscure any copyright or other proprietary notice.
The Materials may contain trademarks, services marks and logos that are the property of
third parties. You are not permitted to use these trademarks, services marks or logos
without prior written consent of such third parties.
Realtimepublishers.com and the Realtimepublishers logo are registered in the US Patent
& Trademark Office. All other product or service names are the property of their
respective owners.
If you have any questions about these terms, or if you would like information about
licensing materials from Realtimepublishers.com, please contact us via e-mail at
info@realtimepublishers.com.

Chapter 1

1
[Editors Note: This eBook was downloaded from Content Central. To download other eBooks
on this topic, please visit http://www.realtimepublishers.com/contentcentral/.]

Chapter 1: Introducing Active Directory
As computer networks have evolved over the years, the focus in enterprise computing has shifted
away from a PC network operating system-centric (NOS) model to one based on the concept of
directories, or directory services. A directory service is a network service that stores information
about network resources and makes those resources available to network users and applications.
Directories also provide an environment that allows for the uniform naming, location, access,
management, and security of network resources. These days, nearly all companies with large
enterprise-level networks, and even many of those with small to midsized networks, employ one
or more directories within their organizations. Although the concept of directories has been
around for some time, it is only in recent years that the directory has moved into the limelight of
network computing.
Directories provide a number of advantages, not the least of which is user convenience and
consistent security. Prior to the adoption of directoriesmost notable in the Novell NetWare 2.x
and 3.x daysusers would maintain separate accounts on each server they accessed. When the
time came to change passwords, chaos often ensued. Directories solve this (and other) problems
by providing a single location for information such as security accounts, allowing this
information to be used uniformly across the enterprise.
Although Microsofts Windows NT operating system (OS) introduced a very basic directory in
the form of the NT Directory Service (whose heart and soul is the Security Accounts Manager
SAMdatabase), this directory has several major limitations. Among these are:
Non-hierarchical structure and namespaceNTs directory uses a flat, non-hierarchical
directory structure that doesnt support the naming and structural needs of complex
organizations.
Lack of extensibilityNTs directory stores only basic user information and cant be
inherently extended. This lack of extensibility requires applicationssuch as Microsofts
popular Exchange Server messaging platformto maintain their own, independent
directories capable of storing application-specific data.
Lack of scalabilityThe NT directory is stored inside the NT system registry database;
due to this architecture, the maximum number of security accounts tops out in the
neighborhood of around 40,000 per domain.
Poor manageability featuresAdministration roles arent layered and cant be natively
delegated.
Poor directory replication performanceBecause NTs architecture is bandwidth- and
network topology-ignorant, the NT OS cant automatically tune replication frequency and
bandwidth usage to adapt to variable WAN link speeds between multiple physical
locations within a network.
Single-master, single-point-of-failure architectureNTs architecture calls for a single
server in each network domainthe Primary Domain Controller (PDC)to house the
master copy of the directory, thus making it a single point of failure for logon
authentication for the entire domain.
Chapter 1

2
In Windows 2000 (Win2K), NTs successor OS, Microsoft set out to deliver a directory capable
of addressing each of these limitations. Win2Ks new directory service, dubbed Active Directory
(AD), provides an industrial-strength directory service that can serve the needs of both small and
very large organizations, and everyone in between. Because it stores its data outside the system
registry, AD has virtually unlimited storage capacity (AD databases can contain hundreds of
millions of entries, as compared with the tens of thousands NT is capable of storing). AD allows
administrators to define physical attributes of their network, such as individual sites and their
connecting WAN links, as well as the logical layout of network resources such as computers and
users. Using this information, AD is able to self-optimize its bandwidth usage in multi-site WAN
environments. AD also introduces a new administration model that provides a far more granular
and less monolithic model than is present under NT 4.0. Finally, AD also provides a central point
of access control for network users, which means that users can log on once and gain access to
all network resources.
Although other directories such as Banyans StreetTalk and Novells NDS have existed for some
time, many NT-centric organizations have opted to wait and use Microsofts entry in the
enterprise directory arena as the foundation for their organization-wide directory environment.
Consequently, AD represents the first foray into the larger world of directories and directory
management for many organizations and network administrators.
Windows Server 2003 (WS2K3) introduces a new version of AD that is essentially a more
mature, refined version of the AD introduced in Win2K. Several minor enhancements have been
made to improve performance, improve the experience of interacting with the directory, and to
enhance the directorys manageability. AD as implemented in WS2K3 is completely backward-
compatible with Win2Ks version of AD; a series of functional levels disable functionality that
isnt backward-compatible until the entire organization is running the latest version.
WS2K3 AD is definitely an evolutionary product, meaning it represents small but important changes
over prior versions. Win2Ks AD, however, could reasonably be called a revolutionary product, as it
represented a complete and total change over the prior directory offered in Windows.
With widespread adoption of AD finally a reality, the directory is taking on new and unforeseen
roles within most organizations. The concept of the directory as a single repository for user
accounts has been vastly expanded. Todays directories are expected to serve as centralized
identity management applications. Everything related to the identity of security principalsuser
names, digital certificates, application information, and moreis being stored in the directory. In
its relatively short life, AD has become one of the most mission-critical applications in
organizations that have deployed it, serving as the lynchpin for a variety of enterprise
applications and providing centralized identity management across the organization.
Chapter 1

3
The Importance of Directories and Directory Management
Directories provide a logically centralized repository for all critical information within an
enterprise network. Rather than spreading information around between many different databases,
organizations can use a centralized directory such as AD to consolidate all critical company
information into a single shared network resource. In addition to improving organizational
efficiency, this move also allows for significant reductions in the total cost of ownership (TCO)
of the corporate network. The concept of wholesale migration from NT (or non-Microsoft)
directories to AD has also become more feasible with both existing and announced support from
major application vendors, including those producing enterprise resource planning (ERP),
groupware, Human Resources (HR), and accounting packages.
Many Eggs, One Basket
Although the large-scale centralization and consolidation of critical data is one of the most
significant benefits of migrating to a directory-based NOS such as AD, this also represents one
of its greatest potential weaknesses. Whenever critical information is moved from a distributed
model to one that is highly centralized, the tolerance for downtime and problems is greatly
reduced, and at the same time, the risk of loss due to downtime is increased. One excellent
example of this potential problem is the Windows registry: Prior to NT and Windows 95,
Windows and Windows-based applications stored information in independent text files carrying
an INI filename extension. NT and Windows 95 introduced the centralized registry, which
contained all the information previously stored in independent files. Prior to the registry, a single
corrupted INI file would affect, at most, one application or aspect of Windows; a corrupted
registry, however, can render the entire system useless.
Furthermore, many organizations planning AD migrations have chosen to focus the majority of
their preparatory efforts and budgets on issues such as legacy hardware and software
compatibility and application interoperability in the Win2K or WS2K3 environment. Although
these are certainly worthwhile and important considerations, they are by no means the only steps
required to guarantee a successful AD deployment. In addition to compatibility and capacity
issues, IT departments within these organizations must determine which additional tools,
information, and training will be required to properly support their Windows network
environments on a day-to-day basis.
The moral is that by consolidating so much information into AD, you run the risk of creating a
single point of failure within your organizationthe single point of failure being AD itself. Its
therefore critical that you invest the necessary planning resources to ensure that AD is a robust,
fault-tolerant directory. AD provides all the necessary technologies and features to be a very
robust directory service, provided you design it to be so.
Chapter 1

4
New Tools for New Times
To effectively support AD-based networks, administrators need to engage in additional network
management activities beyond those taken with previous versions of NT in order to maintain the
same levels of network availability they had in the past. With any computer network, it is
imperative that critical statisticssuch as server CPU, memory, and disk utilization, as well as
network connectivity statisticsbe monitored on an ongoing basis. Win2K and WS2K3
introduce additional components, services, and dependencies that must also be regularly
monitored alongside these other metrics. These elements, which collectively comprise
Windowss core infrastructure, include items such as domain controllers, AD databases and
services, the Global Catalog (GC), intra- and inter-site replication, site links, and DNS servers.
Because Windows and Windows-centric applications rely heavily on these services and
components for proper operation, administrators must be able to guarantee not only their general
availability but also an acceptable baseline of performance. Failure to do so can result in severe,
network-wide problems including slow or failed user logon authorizations, failed convergence of
directory data, the inability to access critical applications, printing problems, and similar
maladies. These problems are of particular concern for IT shops that offer service-level
agreements (SLAs) to their corporate parents or clients. To be able to properly maintain their
Windows infrastructure, IT shops will not only need Win2K- and WS2K3-aware monitoring and
management tools but also specific knowledge about what needs to be monitored, what
thresholds must be set to maintain acceptable levels of performance, and what needs to be done
in the event that problems should occur.
Win2K, WS2K3, and More
With the recent downturn in IT budgets and staff, todays companies are less likely to undertake
wholesale migrations to new versions of Windows. Functioning Win2K machines are likely to be left in
place as file servers, print servers, application servers, and even domain controllers for the foreseeable
future. Although WS2K3 may be adopted for new deployments, companies arent necessarily going to
replace working Win2K machines. WS2K3s version of AD is specifically designed to accommodate this
mixed-version environment, although you will obviously not be able to take advantage of every new
WS2K3 feature when operating in a mixed-version environment.
Throughout this book, the assumption will be that administrators are working in a mixed-version
environment containing both Win2K and WS2K3 servers in varying roles. Features, problems, tools, and
techniques specific to WS2K3 will be identified as such, providing administrators with an easy way of
identifying things which will, or will not, work in their specific environments. Any discussion specific to an
all-WS2K3 environment will also be called out as such.
Meet AD
Of all of the elements that comprise a Win2K or WS2K3 network, the most important by far is
AD, Windows centralized directory service. However, before we delve into the specifics of AD,
lets first define some of the fundamental terms and concepts related to directory-enabled
networks. A directory (which is sometimes also referred to as a data store) maintains data about
objects that exist within a network, in a hierarchical structure, making the information easier to
understand and access. These objects include traditional network resources such as user and
machine accounts, shared network resources (such as shared directories and printers), and
resources such as network applications and services, security policies, and virtually any other
type of object an administrator or application wants to store within the directory data store.
Chapter 1

5
As mentioned earlier, a directory service is a composite term that includes both the directory data
store and the services that make the information within the directory available to users and
applications. Directory services are available in a variety of different types and from different
sources. OS directories, such as Microsofts AD and Novells NDS, are general purpose
directories included with the NOS and are designed to be accessible by a wide array of users,
applications, and devices. There are also some applications, such as ERP systems, HR systems,
and email systems (for example, Microsoft Exchange) that provide their own directories for
storing data specific to the functionality of those applications.
Microsoft Exchange Server 200x is a notable exception to this and is completely integrated with AD.
Exchange Servers installation process extends ADs structure to accommodate Exchange-specific
data and subsequently uses AD to store its own directory information.
AD is Microsofts directory service implementation in the Win2K and WS2K3 server OSs. AD
is hosted by one or more domain controllers, and is replicated in a multi-master fashion between
those domain controllers to ensure greater availability of the directory and network as a whole.
Any Windows server running AD is considered to be a domain controller; domain controllers,
then, are the only servers that implement the various services and features that comprise AD. In
addition to providing a centralized repository for network objects and a set of services for
accessing those objects, AD provides security in the form of access control lists (ACLs) on
directory objects that protect those objects from being accessed by unauthorized parties.
There are many features of other applicationssuch as Microsoft Exchange Serverthat take
advantage of AD, although those applications themselves do not need to be running on a domain
controller.

The term multi-master indicates that multiple read/write copies of the database exist simultaneously,
one on each domain controller. Thus, each domain controller is effectively an equal peer of the other
controllers, and any controller can write directory updates and propagate those updates to other
controllers. This functionality is in notable contrast to NT 4.0s single-master PDC/BDC replication
topology wherein a single domain controller, the PDC, houses a read/write copy of the database.
AD includes a complex and robust replication infrastructure that is designed to accommodate this
multi-master model. For example, conflicts, which occur when two controllers change the same thing
at nearly the same time, are resolved automatically.
Chapter 1

6
The AD Database
At a file-system level, AD uses Microsofts Extensible Storage Engine (ESE) to store the
directory database. Administrators familiar with Microsoft Exchange Server may recognize this
engine as the same database technology used in that product. Like Exchange Server, ADs
database employs transactional log files to help ensure database integrity in the case of power
outages and similar events that interfere with the successful completion of database transactions.
In addition, AD shares Exchanges ability to perform online database maintenance and
defragmentation. At the file level, AD stores its database in a single database file named Ntds.dit,
a copy of which can be found on every domain controller.
Although the building blocks that make up AD are largely masked by the directorys high-level
management interfaces and APIs, the physical aspects of the directory are nonetheless an
important consideration for Windows administrators. For example, it is critical that all volumes
on domain controllers hosting the AD database and its transaction logs maintain adequate levels
of free disk space at all times. For performance reasons, it is also important that the AD
databases on these machines not become too heavily fragmented.
AD is a database, which effectively turns Windows domain controllers into critical database
servers on the network. These servers should therefore be treated no differently than any other
important database server in terms of fault tolerance preparation (for example, disk redundancy,
backups, and power protection) and capacity planning.
Logical Architecture of AD
To gain an appreciation for and understanding of AD and AD management concepts, its
important to first understand ADs logical architecture. In this section, well discuss the most
important concepts associated with AD, concepts which form the foundation of all Windows
networks.
Objects and Attributes
J ust as the primary item of storage in a file system is a file, the primary item of storage in AD is
an object. Objects can take many different forms; for example, users, computers, and printers all
exist as objects within the directory. However, other items you might not immediately think of
are also stored as objects; for example, policies that define which applications a particular group
or user should have on their computer(s).
AD uses an object-oriented approach to defining directory objects. That is to say there exists a
set of classes, which define the kinds of objects one can create (or instantiate, as in creating an
instance of...) within the directory. Each classsuch as user, computer, and so forthhas a set
of attributes that define the properties associated with that class. For example, AD has a user
class with attributes such as First Name, Address, and so on.

Chapter 1

7
There are special types of objects in AD known as container objects that you should be familiar with.
Put simply, container objects are objects that may contain other objects. This design allows you to
organize a tree or hierarchy of objects. Examples of container objects include organizational unit (OU)
and domain objects. Container objects may hold both objects and/or other container objects. For
example, an OU object can contain both regular objects such as users and computers and other OU
container objects.

Although its perfectly acceptable to say create in lieu of instantiate when referring to the
generation of a new object within the directory, well use the latter more frequently in this book. The
reason is that instantiate is more appropriate when you consider the underlying event that actually
occursthat being the creation of an instance of an object.
The Schema
As you might imagine, all of the object classes and attributes discussed thus far have some kind
of underlying reference that describes thema sort of dictionary for AD. In Windows
parlance, this dictionary is referred to as the schema. The AD schema contains the definitions
of all object types that may be instantiated within the directory. The AD schema is also
extensible, meaning it can be extended to include additional classes and attributes to support
future features, other applications, and so forth.
Even 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 understand the relationship between object classes, objects, and the schema, lets go back to
the object-oriented model upon which the AD schema is based. As is the case with object-
oriented development environments (such as C++and J ava), a class is a kind of basic definition
of an object. When I instantiatean object of a certain class, I create an instance of that particular
object class. That object instance has a number of properties associated with the class from
which it was created. For example, suppose I create a class called motorcycle that has
attributes such as color, year, and enginesize. I can instantiate the class motorcycle and
create a real object called Yamaha YZF600R6 with properties such as red (for the color
attribute), 2000 (for the year attribute), and 600 (for the motorcycle engines size in CCs).
Chapter 1
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 might create an object of the class user called Craig Daily,
which has properties such as password, address, and home directory location. You can view the
AD schema through the Active Directory Schema Microsoft Management Console (MMC) snap-
in, which Figure 1.1 shows.

Figure 1.1: Viewing the AD schema by using the Active Directory Schema MMC snap-in.
Editing the schema is a potentially dangerous activityyou need to know exactly what youre doing
and why youre doing it. Before you make schema changes, be sure to back up the current AD
database contents and schema (for example, by using ntbackup.exe or a third-party utilitys System
State backup option on an up-to-date domain controller).

8
Chapter 1

9

Viewing the AD Schema
Some of you may be curious about how to use the Active Directory Schema MMC snap-in to view the AD
schema. Its not immediately obvious how to do so using the MMC console because the Active Directory
Schema console isnt available in the default list of snap-ins. To use this snap-in, you need to manually
register it by selecting Start, Run (or entering a command-prompt session), and typing
r egsvr 32 schmmgmt . dl l
Youll receive a message stating that the OS successfully registered the .dll file. You can now load and
use the Active Directory Schema snap-in through the MMC utility. For example, you can open an MMC
session and choose Add/Remove Snap-in from the Console menu, then select Active Directory Schema
from the Add Standalone Snap-In dialog box (Figure 1.1 shows the Active Directory Schema snap-ins
view of the AD schema).
To modify the AD schema, you need to use a different utility: the MMC ADSI Edit snap-in. ADSI Edit is
essentially a low-level AD editor that lets you view, change, and delete AD objects and object attributes.
In terms of usefulness and potential danger, ADSI Edit is to AD what the regedit or regedt32 registry
editors are to the system registry.
To use the ADSI Edit utility to make schema modifications, you first need to be a member of the Schema
Admins group. The Schema Admins group is a universal group in native-mode Win2K domains (and in
WS2K3 domains running in Win2K native mode or later) and a global group in other AD domains (that is,
those that still are still running NT 4.0 domain controllers or have no more NT domain controllers but
havent yet been converted to Win2Ks native mode or a later WS2K3 functional level). To use the snap-
in, first register the associated adsiedit.dll file at the command line:
r egsvr 32 adsi edi t . dl l
The ADSI Edit snap-in will be available from the MMCs Console/Add/Remove snap-in menu. Once
youve added the snap-in, you can use the ADSI Edit console to make changes to AD objects and
attributes.
LDAP
One of the early design decisions that Microsoft made regarding AD was the use of an efficient
directory access protocol known as the Lightweight Directory Access Protocol. LDAP also
benefits from its compatibility with other existing directory services. This compatibility, in turn,
provides for the interoperability of AD with these other directory services.
AD supports LDAP versions 2 and 3.
Chapter 1

10
LDAP specifies that every AD object be represented by a unique name. These names are formed
by combining information about domain components, OUs, and the name of the target object,
known as a common name. Table 1.1 provides each of these LDAP name components and their
descriptions.
Attribute Type DN Abbreviation Description
Domain-Component DC An individual element of the DNS domain name of
the objects domain (for example, com, org, edu,
realtimepublishers, Microsoft)
Organizational-Unit-Name OU An OU container object within an AD domain
Common-Name CN Any object other than domain components and
OUs (such as printers, computers, and users)
Organization-Name O The name of a single organization, such as a
company; although part of the X.500 and LDAP
standards, Organization is generally not used in
directories such as AD that use domain
components to organize the tree structure
Locality-Name L The name of a physical locale, such as a region or
a city; although part of the X.500 and LDAP
standards, Locality is generally not used in
directories such as AD that use domain
Country-Name C The name of a country; although part of the X.500
and LDAP standards, Country is generally not used
in directories such as AD that use domain
Table 1.1: LDAP name components.
For example, the LDAP name for the user object for a person named Don J ones in the
realtimepublishers.com domains Marketing OU would be as follows:
CN=Don J ones, OU=Mar ket i ng, DC=r eal t i mepubl i sher s, DC=com
This form of an objects name as it appears in the directory is referred to as the objects
distinguished name (DN). Alternatively, an object can also be referred to using its relative
distinguished name. The RDN is the portion of the DN that refers to the target object within its
container. In the previous example, the RDN of the user object would simply be Don J ones.
Domains, Trees, and Forests
A significant advantage of AD is that it allows for a flexible, hierarchical design. To facilitate
this design, the AD structure employs several logical components. The first of these components
is the domain. A domain serves as the core unit in ADs logical structure and is defined as a
collection of computers that share a common directory database. In fact, this definition is
basically identical to that of NT domains. Like NT domains, AD domains have unique names.
However, unlike the NetBIOS-based domain names used in NT, AD domains use a DNS naming
structure (for example, realtimepublishers.com or mydomain.org).
Chapter 1

11
Domains also have several other important characteristics. First, they act as a boundary for
network security: each domain has its own separate and unique security policy that defines items
such as password expiration and similar security options. Domains also act as an administrative
boundary, because administrative privileges granted to security principals within a domain do
not automatically transfer to other domains within AD. Finally, domains act as a unit of
replication within ADas all servers acting as domain controllers in an AD domain replicate
directory changes to one another, they contain a complete set of the directory information related
to their domain.
AD domain names dont need to be Internet-registered domain names ending in Internet-legal top-
level domains (such as .com, .org, and .net). For example, it is possible to name domains with
endings such as .pri, .msft, or some other ending of your choosing. This of course assumes that the
domains DNS servers arent participating in the Internet DNS namespace hierarchy (which is by far
the most common scenario, due to security considerations with exposing internal DNS servers to the
Internet). If you do elect to use standard Internet top-level domains in your AD domain names, you
should register these names on the Internet even if they dont participate in the Internet DNS
namespace. The reason is that most organizations are connected to the Internet, and using
unregistered internal domain names that may potentially be registered on the Internet could cause
name conflicts.
ADs design also integrates the concepts of forests and trees. A tree is a hierarchical arrangement
of AD domains within AD that forms a contiguous namespace. For example, assume a domain
named xcedia.com exists in your AD structure. The two subdivisions of xcedia.com are europe
and us, which are each represented by separate domains. Within AD, the names of these domains
would be us.xcedia.com and europe.xcedia.com. These domains would form a domain tree
because they share a contiguous namespace. This arrangement demonstrates the hierarchical
structure of AD and its namespaceall of these domains are part of one contiguous related
namespace in the directory; that is to say, they form a single domain tree. The name of the tree is
the root level of the tree, in this case, xcedia.com. Figure 1.2 shows the single-domain tree
described in this example.
Chapter 1

Figure 1.2: An AD forest with a single tree.
A forest is a collection of one or more trees. A forest can be as simple as a single AD domain, or
more complex, such as a collection of multi-tiered domain trees.
Lets take this single-tree example scenario a step further. Assume that within this AD
environment, the parent organization, Xcedia, also has a subsidiary company with a domain
name of Realtimepublishers.com. Although the parent company wants to have both
organizations defined within the same AD forest, it wants their domain and DNS names to be
unique. To facilitate this configuration, you would define the domains used by the two
organizations within separate trees in the same AD forest. Figure 1.3 illustrates this scenario. All
domains within a forest (even those in different trees) share a schema, configuration, and GC
(well discuss the GC in a later section). In addition, all domains within a forest automatically
trust one another due to the transitive, hierarchical Kerberos trusts that are automatically
established between all domains in an AD forest.
The Kerberos version 5 authentication protocol is a distributed security protocol based on Internet
standards and is the default security mechanism used for domain authentication within or across AD
domains. Kerberos replaces NT LAN Manager (NTLM) authentication used in NT Server 4.0 as the
primary security protocol for access to resources within or across AD domains. AD domain controllers
still support NTLM to provide backward compatibility with NT 4.0 machines.

12
Chapter 1

Figure 1.3: Example of a multi-tree AD forest.
In the case of a forest with multiple trees, the name of the forest is the name of the first domain
created within the forest (the root domain of the first tree created in the forest).
Although cohabitation of different organizations within the same AD forest is appropriate in
some circumstances, in others, it is not. For example, unique security or schema needs may
require two companies to use entirely different AD forests. In these situations, Kerberos trusts
arent established between the two forests, but you can create explicit trusts between individual
domains in different forests.
Each AD forest contains a group named Enterprise Admins. Members of this special group have
full control over each domain in the forest. In many companies, then, political reasons make it
necessary to create multiple forests. Suppose in the previous example that the folks running
Xcedia.com and the folks running Realtimepublishers.com need to maintain their own,
independent IT environments. In that case, having the two trees in one forest might not be
advisable, because members of the forest-wide Enterprise Admins group would have control
over both domain trees.
Trusts, therefore, are important in any AD design. Within a single domain tree, each domain has
a two-way, transitive trust with other domains in the tree. For example, the us.xcedia.com
domain trusts the xcedia.com domain and vice-versa. The us.xcedia.com domain and the
europe.xcedia.com domains also enjoy an implicit two-way trust through their shared trust of the
xcedia.com domain. The trust relationship simply means that security principalssuch as
usersin one trusted domain can be assigned access permissions in another trusting domain; the
mere existence of the trust, however, doesnt automatically confer any special permissions.

13
Chapter 1

14
Win2K provides the ability to create one-way, nontransitive trusts. For example, the xcedia.com
domain might be configured to trust the realtimepublishers.com domain. As the trusted domain,
realtimepublishers.com users could be given permissions to resources in the trusting xcedia.com
domain. However, the reverse would not be true because the trust is one-way. Whats more,
xcedia.coms child domains wouldnt participate in the trust because this manual, inter-domain
trust is nontransitive.
WS2K3 domains running at the highest forest functional level can also establish one-way,
nontransitive trusts between other entire forests. Microsoft provides this capability to correct a
problem with Win2K in the Enterprise Admins group. Because this group has overriding control
over every domain in a forest, many organizations were forced to create multiple forests to
maintain their desired security boundaries. However, without trusts between forests, providing
users in other forests with access to resources was difficult, often requiring users to maintain
accounts in each of an organizations forests, and partially defeating one of the directorys
primary purposes which is to have one user account per person. WS2K3 forest trusts allow
forests to be used as an ultimate security boundary, while still providing cross-forest access when
needed.
There are several resources you might find helpful when planning your organizations AD structure
and namespace, such as the Microsoft white papers that contain valuable information about AD
design and architectural concepts, including Active Directory Architecture and Domain Upgrades
and Active Directory. These and others technical documents related to AD can be found on
Microsofts Web site at http://www.microsoft.com/windows2000/server.
Organizational Units
An OU is a special container object that is used to organize other objectssuch as computers,
users, and printerswithin a domain. OUs can contain all these object types, and even other
OUs (this type of configuration is referred to as nested OUs). OUs are a particularly important
element of AD for several reasons. First, they provide the ability to define a logical hierarchy
within the directory without creating additional domains. OUs allow domain administrators to
subdivide their domains into discrete sections and delegate administrative duties to others. More
importantly, this delegation can be accomplished without necessarily giving the delegated
individuals administrative rights to the rest of the domain. As such, OUs facilitate the
organization of resources within a domain. Figure 1.4 shows an example of OUs within a
domain.
There are several models used for the design of OU hierarchies within domains, but the two most
common are those dividing the domain organizationally (for example, by business unit) or
geographically.
Chapter 1

Figure 1.4: OUs within a domain.
Broadly speaking, your OU structures should reflect the way you plan to delegate control over
your domains objects. If every object will be administered by one small group of administrators,
one OU might be all you need. If each office in your organization will be managed at least
somewhat independently (perhaps giving a local office administrator the ability to reset
passwords, for example), having one OU per office will facilitate your administrative model.
The Global Catalog
Because AD is the central component of a Windows network, network clients and servers
frequently query it. In order to increase the availability of AD data on the network as well as the
efficiency of directory object queries from clients, AD includes a service known as the GC. The
GC is a separate database from AD and contains a partial, read-only replica of all the directory
objects in the entire AD forest.

15
Chapter 1

16
Only Windows servers acting as domain controllers can be configured as GC servers. By default,
the first domain controller in a Windows forest is automatically configured to be a GC server
(this designation can be moved later to a different domain controller if desired; however, every
forest must contain at least one GC). Like AD, the GC uses replication in order to ensure updates
between the various GC servers within a domain or forest. In addition to being a repository of
commonly queried AD object attributes, the GC plays two primary roles on a Windows network:
Network logon authenticationIn native-mode domains (networks in which all domain
controllers have been upgraded to Win2K or later, and the domains functional level has
been manually set to the appropriate level), the GC facilitates network logons for AD-
enabled clients. It does so by providing universal group membership information to the
account sending the logon request to a domain controller. This applies not only to regular
users but also to every type of object that must authenticate to AD (including computers).
In multi-domain networks, at least one domain controller acting as a GC must be
available in order for users to log on. Another situation that requires a GC server occurs
when a user attempts to log on with a user principal name (UPN) other than the default. If
a GC server is not available in these circumstances, users will only be able to logon to the
local computer (the one exception is members of the domain administrators group, who
do not require a GC server in order to log on to the network).
Directory searches and queriesWith AD, read requests such as directory searches and
queries, by far tend to outweigh write-oriented requests such as directory updates (for
example, by an administrator or during replication). The majority of AD-related network
traffic is comprised of requests from users, administrators, and applications about objects
in the directory. As a result, the GC is essential to the network infrastructure because it
allows clients to quickly perform searches across all domains within a forest.
Although mixed-mode Win2K domains do not require the GC for the network logon authentication
process, GCs are still important in facilitating directory queries and searches on these networks and
should therefore be made available at each site within the network.

Domain Modes and Functional Levels
Lets establish some correlations between Win2K domain modes and WS2K3 domain functional
levels. A Win2K domain in mixed mode is similar to a WS2K3 domain in the Win2K mixed functional
levelboth allow for the presence of NT BDCs. Once all domain controllers are running at least Win2K, a
WS2K3 domain can be raised to Win2K native functional level; Win2K domains can be placed in their
native mode. Doing so enables new functionality such as universal security groups. When all domain
controllers are running WS2K3, the domain can be raised to WS2K3 functional level, and even more
featuresall WS2K3-specificbecome available, including enhanced replication capabilities.
WS2K3 forests have functional levels, too. In Win2K functional levels, forests can accommodate AD
domains of any kind. At the WS2K3 functional level, a forest can contain only domains also running in
their WS2K3 functional level.
Chapter 1
Physical Structure of AD
Thus far, our discussion of AD has focused on the logical components of the directorys
architecture; that is, the components used to structure and organize network resources within the
directory. However, an AD-based network also incorporates a physical structure, which is used
to configure and manage network traffic.
Domain Controllers
The concept of a domain controller has been around since the introduction of NT. As is the case
with NT, a Win2K or WS2K3 domain controller is a server that houses a replica of the directory
(in the case of Win2K or WS2K3, the directory being AD rather than the NT SAM database).
Domain controllers are also responsible for replicating changes to the directory to other domain
controllers in the same domain. Additionally, domain controllers are responsible for user logons
and other directory authentication as well as directory searches.
Fortunately, Win2K and WS2K3 do away with NTs restriction that converting a domain controller to a
member server or vice-versa requires reinstallation of the server OS. Servers may be promoted or
demoted to domain controller status dynamically (and without reinstallation of Windows itself) by
using the Dcpromo.exe domain controller promotion wizard.
At least one domain controller must be present in a domain, and for fault tolerance reasons its a
good idea to have more than one domain controller at any larger site (for example, a main office
or large branch office).
www.netpro.com
Directory Replication
As weve discussed, domain controllers are responsible for propagating directory updates they
receive (for example, a new user object or password change) to other domain controllers. This
process is known as directory replication, and can be responsible for a significant amount of
WAN traffic on many networks.
AD is replicated in a multi-master fashion between all domain controllers within a domain to
ensure greater availability of the directory and network as a whole. The term multi-master
indicates that multiple read/write copies of the database exist simultaneously on each domain
controller computer. Thus, each domain controller is effectively a peer of the other controllers,
and any domain controller can write directory updates and propagate those updates to other
domain controllers. This is in notable contrast to NT 4.0s single-master PDC/BDC replication
topology wherein a single domain controller, the PDC, houses the only read/write copy of the
database; other domain controllersBDCscontain a read-only copy replicated from the PDC.
ADs replication design means that different domain controllers within the domain may hold different
data at any given timebut usually only for short periods of time. As a result, individual domain
controllers may be temporarily out of date at any given time and unable to authenticate a logon
request. ADs replication process has the characteristic of bringing all domain controllers up to date
with each other; this characteristic is called convergence.

17
Chapter 1

18
The Operations Masters
Although multi-master replication is a central feature of AD networks, the potential for collisions
and conflict between multiple servers makes this functionality inappropriate for some network
operations and roles. AD accommodates these special cases by electing specific domain
controllers to serve as operations masters (also referred to as flexible single master operations
FSMOs) for each of these network roles. There are five different types of operations masters in
ADtwo that are forest-specific and three that are domain-specific. AD automatically elects the
operation master servers during the creation of each AD forest and domain, assigning them to the
first domain controller installed into a new forest.
When you use the Active Directory Installation Wizard to create the first domain in a new forest,
all five of the FSMO roles are automatically assigned to the first domain controller in that
domain. In a small AD forest with only one domain and one domain controller, that domain
controller continues to own all the operations master roles. In a larger network, whether with one
or multiple domains, you can re-assign these roles to one or more of the other domain
controllers. The following list highlights the two forest-wide operations master roles:
Schema masterThe domain controller that serves the schema master role is responsible
for all updates and modifications to the forest-wide AD schema. The schema defines
every type of object and object attribute that can be stored within the directory.
Modifications to a forests schema can only be done by members of the Schema
Administrators group, and can be done only on the domain controller that holds the
schema master role.
This is not to say that schema changes require physical access to the domain controller holding the
schema master role; ADs administrative tools are smart enough to seek out the schema master and
connect to it remotely when necessary.
Domain naming masterThe domain controller elected to the domain naming master
role is responsible for making changes to the forest-wide domain name space of AD. This
domain controller is the only one that can add or remove a domain from the directory or
add/remove references to domains in external directories.
The three domain-specific operations master roles are as follows:
PDC emulatorIf an AD domain contains non-AD-enabled clients or is a mixed-mode
domain containing NT BDCs, the PDC emulator acts as an NT PDC for these systems. In
addition to replicating the NT-compatible portion of directory updates to all BDCs, the
PDC emulator is responsible for time synchronization on the network (which is important
for Windows Kerberos security mechanism as well as some aspects of AD replication),
and processing account lockouts and client password changes.
Win2K and later clients synchronize their system clocks with the domain controller that authenticates
them to the domain. Domain controllers synchronize their time with the domains PDC emulator. The
PDC emulators in child domains synchronize their time with the PDC emulators of their parent; the
forest root domains PDC emulator should be configured to synchronize with some authoritative
external time source, such as the US Naval Observatorys atomic clock.
Chapter 1

19
RID masterThe RID (relative ID) master allocates sequences of RIDs to each domain
controller in its domain. Whenever a domain controller creates an object such as a user,
group, or computer, that object must be assigned a unique security identifier (SID). A
SID consists of a domain security ID (this ID is identical for all SIDs within a domain)
and a RID. When a domain controller has exhausted its internal pool of RIDs, it requests
another pool from the RID master domain controller.
Infrastructure masterWhen an object in one domain is referenced by an object in
another domain, it represents the reference by the Globally Unique Identifier (GUID), the
SID (for objects that reference security principals), and the DN of the object being
referenced. The infrastructure master is the domain controller responsible for updating an
objects SID and DN in a cross-domain object reference. The infrastructure master is also
responsible for updating all inter-domain references any time an object referenced by
another object moves (for example, whenever the members of groups are renamed or
changed, the infrastructure master updates the group-to-user references). The
infrastructure master distributes updates using multi-master replication.
Except where there is only one domain controller in a domain, never assign the infrastructure master
role to the domain controller that is also acting as a GC server. If you use a GC server, the
infrastructure master will not function properly. Specifically, the effect will be that cross-domain object
references in the domain will not be updated. In a situation in which all domain controllers in a domain
are also acting as GC servers, the infrastructure master role is unnecessary because all domain
controllers will have current data.
Because the operations masters play such critically important roles on a Windows network, its
essential for proper network operation that all the servers hosting these roles are continually
available.
Sites
The final, and perhaps most important component of ADs physical structure, is a site. Sites
allow administrators to define the physical topology of a Windows network, something that
wasnt possible under NT. Sites can be thought of as areas of fast connectivity (for example,
individual office LANs), but are defined within AD as a collection of one or more IP subnets.
When you look at the structure of IP, this begins to make sensedifferent physical locations on
a network are typically going to be connected by a router, which in turn, necessitates the use of
different IP subnets on each network. Its also possible to group multiple, non-contiguous IP
subnets together to form a single site.
So why are sites important? The primary reason is that the definition of sites makes it possible
for AD to gain some understanding of the underlying physical network topology, and tune
replication frequency and bandwidth usage accordingly (under NT, this could only be done via
manual adjustments to the replication service). This intelligence conferred by the knowledge
of the network layout has numerous other benefits. For example, it allows AD-enabled
computers hosting users who are logging on to the network to automatically locate their closest
domain controller and use that controller to authenticate, rather than crossing the WAN to do so.
In a similar fashion, sites give other components within a Windows network new intelligence.
For example, a client computer connecting to a server running the Distributed File System (Dfs)
feature in Windows can use sites to locate the closest Dfs replica server.
Chapter 1

20
Its important to remember that sites are part of the physical structure of AD and are in no way
related to the logical constructs weve already discussed, such as domains and OUs. Its possible
for a single domain to span multiple sites, or conversely, for a single site to encompass multiple
domains. The proper definition of sites is an essential aspect of AD network design planning.
For sites that house multiple domains (for example, an organization that divides business units into
domains rather than OUs, thus hosting multiple business unit domains on a single site), its important
to remember to place at least one, and possibly two, domain controllers for each domain that users
will authenticate to from that site (because users can only authenticate to a domain controller from
their domain). This outlines the biggest disadvantage of the business unit domain model: the potential
for requiring many domain controllers at each and every site.
ADs Backbone: DNS
The TCP/IP network protocol plays a far larger role in Win2K and WS2K3 than with previous
versions of NT. Although other legacy protocols such as IPX continue to be supported, most of
the internal mechanics of modern Windows networks and AD are based on TCP/IP.
In Windows, as with all TCP/IP-based networks, the ability to resolve names to IP addresses is
an essential service. A bounded area within which a given name can be resolved is referred to as
a namespace. In NT-based networks, NetBIOS is the primary namespace and WINS is the
primary name-to-IP address resolution service. With Win2K and later, Microsoft has abandoned
the use of NetBIOS as the primary network namespace and replaced it with DNS, which is also
used on the Internet (although Win2K and later clients continue to support WINS as a secondary,
backward-compatible name resolution mechanism)
Like AD, DNS provides a hierarchical namespace. Both systems also make use of the word
domains, although they define them somewhat differently. Computer systems (called hosts) in
a DNS domain are identified by their fully qualified domain name (FQDN), which is formed by
appending the hosts name to the domain name within which the host is located. Multi-part
domain names (that is, domains that are several levels deep in the hierarchy of the DNS
namespace) are listed with most important domain division (.com, .org, .edu, and so on) at right
and the least importantthe host nameat left. In this way, a host systems FQDN indicates its
position within the DNS hierarchy. For example, the FQDN of a computer named mercury
located in the domain realtimepublishers.com would be mercury.realtimepublishers.com.
Although it is possible to incorporate a DNS namespace within an NT network for name-to-IP
address resolution, the use of DNS is optional and mainly of interest to enterprises running
Internet-based applications or in heterogeneous environments. However, DNS plays a far more
critical role in AD. In Win2K and later networks, DNS replaces NetBIOS as the default name
resolution service. In addition, AD domains use a DNS-style naming structure (an AD domain
might have a name such as santarosa.realtimepublishers.com or mydomain.net), which means
that the namespace of AD domains is directly tied to that of the networks DNS namespace.
This namespace duplication may be limited to the internal DNS namespace for companies using the
Microsoft-recommended configuration of separate DNS configurations for the internal LAN and the
Internet. It is possible, however, to use a split-brain DNS design in which a publicly resolvable DNS
namesuch as realtimepublishers.comis used for both the external and internal namespaces,
without exposing internal DNS servers to the public Internet.
Chapter 1

21
Finally, AD uses DNS as the default locator service; that is, the service used to convert items
such as AD domain, site, and service names to IP addresses. Its important to remember that
although the DNS and AD namespaces in a Windows network are identical in regards to domain
names, the namespaces are otherwise unique and used for different purposes. DNS databases
contain domains and the record contents (host address/A records, server resource/SRV records,
mail exchanger/MX records, and so on) of the DNS zone files for those domains, whereas AD
contains a wide variety of different objects including domains, OUs, users, computer, and Group
Policy objects (GPOs).
Another notable connection between DNS and AD is that Windows DNS servers can be
configured to store their DNS domain zone files directly within AD rather than in external text
files. Although DNS doesnt rely on AD for its functionality, the converse is not true: AD relies
on the presence of DNS for its operation.
Windows includes an implementation of Dynamic DNS (DDNSdefined by Request for
CommentRFC2136) that allows AD-enabled clients to locate important network resources,
such as domain controllers, through special DNS resource records called SRV records. The
accuracy of these SRV records is therefore critical to the proper functioning of a Windows
network (not to mention the availability of the systems and services they reference).
Introduction to AD and Windows Monitoring
As youve already learned, Windows introduces a number of new and important infrastructure
components that does not exist in NT networks. As a result, ensuring the health and availability
of your Windows servers means that you will need to account for these additional components in
your network monitoring routine. Monitoring will provide early warning indicators that will help
mitigate the risk of loss associated with network downtime.
The network monitoring procedures employed by most organizations tend to fall into one of the
following categories:
Limited or no proactive monitoring procedures in placeUnfortunately, IT departments
in some organizations are purely reactive when it comes to network infrastructure
problems, and either do not regularly monitor critical network resources and components
or have limited monitoring in place. Some may conduct regular reviews of server event
logs or generate reports based on these logs, but because such information is delivered in
an on-demand fashion, it is of diminished value when compared with the information
provided by real-time monitoring systems. These organizations will be at high risk of
downtime and financial loss in a Windows environment.
Chapter 1

22
Existing monitoring procedures in place using home-grown or built-in toolsA second
category is where the need for proactive network monitoring is recognized but has been
implemented by the organization using basic, low-cost tools. This includes tools such as
Event Viewer and Performance Monitor, resource kit utilities (NLTEST, BROWMON,
NETDOM, DOMMON, DATALOG, REPADMIN, REPLMON, DFSCHECK, and
similar utilities), and freeware/shareware utilities (utilities that test machine and service
availability using PING, NT service status queries, and queries to well-defined ports such
as DNS, HTTP, and FTP) Although all of these tools can be helpful in ensuring network
health, many require high levels of attention from administrators and suffer from
significant limitations when it comes to scalability and identifying the various types of
problems that may exist on the network.
Existing monitoring procedures in place with full-featured network monitoring tools
The third category is organizations with network monitoring routines built on
sophisticated, full-featured network monitoring software. In addition to many of the basic
services provided by the tools that come with Windows, the resource kits, and
freeware/shareware utilities, these utilities typically include intelligent scripting to
provide sophisticated testing as well as corrective actions in the event of failure. In
addition, many network-monitoring tools include a knowledge base that helps
administrators understand why a problem is happening and offer suggestions as to how to
resolve it. For organizations running large or multi-site Windows networks, this type of
tool is highly recommended.
For administrators of networks that have existing monitoring tools and procedures, the migration
to Win2K and WS2K3 will mainly involve an upgrade of existing tools and staff knowledge
about the vulnerabilities of the new environment. Administrators familiar with Win2K will find
WS2K3 to be remarkably similar, as it represents a more evolutionary set of changes to
Windows (compared with the revolutionary changes seen between NT and Win2K). However, if
your organization has employed a more reactive stance (fix it only when it breaks) with regards
to resolving network problems, youll quickly find that this methodology can be especially
troublesome in a Win2K or WS2K3 environment.
Chapter 1

23
Although it is true that newer versions of Windows provide a far greater level of reliability and
performance than its predecessors, it also involves a higher number of moving parts and
dependencies that need to be accounted for. For example, newer versions of Windows have an
integrated Web browser, integrated media player, integrated Web server, additional networking
services and tools, and so forth. Although legacy NT networks have their own set of
dependencies and vulnerabilities, they are far fewer in number due to NTs simpler (and less
capable) network architecture. Lets quickly review the primary monitoring considerations in an
NT environment:
PDC availability and performanceDue to the single-master nature of NT domains,
there is a high dependence (and thus, a high availability requirement) on the PDC of each
NT domain. Although BDCs exist to create fault-tolerance and load-balancing for client
logon authentication, an NT domain without a PDC essentially grinds to a halt until the
PDC is brought back online or replaced via the manual promotion of a BDC to PDC
status by a network administrator. In addition, network logon traffic loads on domain
controllers should be monitored to assess domain controller performance and the ability
to respond to client network logon authentication requests within an acceptable period of
time.
Domain trust relationshipsOn multi-domain NT networks, there typically exists a
complex array of trust relationships between domains in order to accommodate network
access requirements for the business. NT trust relationships (formed between domain
controllers) are notoriously fragile and prone to failure, and thus require continual
monitoring and testing in order to assure the availability of network resources to users.
Name serversAnother aspect of NT networks requiring continual monitoring is the
availability of network name servers. For the majority of NT-based networks (including
those with Windows 95/2K/XP clients), NetBIOS is the predominant namespace and
Windows Internet Name Service (WINS) the predominant name-to-IP address resolution
service. WINS databases and replication are also notoriously fragile elements of NT
networks, and must be regularly monitored to ensure their functionality. Even for
networks using DNS as the primary name resolution service, the availability of the DNS
name servers is equally important as it is with WINS.
Chapter 1

24

Network browser serviceNT, Windows 9x, and other members of the Windows
product family rely on a network browsing service to build lists of available network
resources (servers, shared directories, and shared printers). The architecture of this
service, which calls for each eligible network node to participate in frequent elections to
determine a browse master and backup servers for each network segment, is another
infamously unreliable aspect of Microsoft networks and requires frequent attention and
maintenance.
Other critical services and applicationsIn addition to name resolution services such as
WINS and DNS, NT environments may house other mission-critical services required for
proper operation of the network or the business in question. For example, critical
applications such as backup, antivirus, mail, FTP, Web, and database servers should be
polled using intelligent service-level queries to verify that they are functioning properly
and at acceptable levels of performance.
Basic network and system metricsAll networks, NT or otherwise, should be monitored
to protect against problems stemming from resource allocation problems on individual
servers or the network itself. For example, any good network monitoring regimen will
include the monitoring of CPU, memory, disk space resource usage, and network
connectivity and bandwidth usage on all critical servers.
AD, Win2K, and WS2K3 Monitoring Considerations
A functioning, modern Windows network is a complex mesh of relationships and dependencies
involving a variety of different systems and services, including AD, DNS, the GC, and
operations master servers. Running an effective Windows network means having a handle of
every aspect of your network environment at all times.
Its no surprise that the primary monitoring consideration in Windows is AD and its related
services and components. This includes responsiveness to DNS and LDAP queries, AD inter-site
and intra-site replication, and a special Windows service called the Knowledge Consistency
Checker (KCC). In addition, the health and availability of services such as DNS, the GC, and Dfs
are also important.
The KCC is a special Windows service that automatically generates ADs replication topology and
ensures that all domain controllers on the network participate in replication.
However, knowing what metrics to monitor is only a first step. By far, the most important and
complex aspect of monitoring network health and performance isnt related to determining what
to monitor but rather how to digest the raw data collected from the array of metrics and make
useful determinations from that data. For example, although it would be possible to collect data
on several dozen metrics (via Performance Monitor) related to AD replication, simply having
this information at hand doesnt tell you how to interpret the data or what you should consider
acceptable tolerance ranges for each metric. A useful monitoring system not only collects raw
data but also understands the inter-relation of that data and how to use the information to identify
problems on the network. This kind of artificial intelligence represents the true value of network
monitoring software.
Chapter 1

25
In order to ensure the health and availability of AD as well as other critical Windows network
services, organizations will need to regularly monitor a number of different services and
components, which are listed in Table 1.2.
Category Potential Problems
Domain controllers/AD Low CPU or memory resources on domain controllers
Low disk space on volumes housing the Sysvol folder, the AD
database (NTDS.DIT) file, and/or the AD transactional log files
Slow or broken connections between domain controllers
Slow or failed client network logon authentication requests
Slow or failed LDAP query responses
Slow or failed Key Distribution Center (KDC) requests
Slow or failed AD synchronization requests
NetLogon (LSASS) service not functioning properly
Directory Service Agent (DSA) service not functioning properly
KCC not functioning properly
Excessive number of SMB connections
Insufficient RID allocation pool size on local server
Problems with transitive or external trusts to Win2K or down-level
NT domains
Low AD cache hit rate for name resolution queries (as a result of
inefficient AD design)
Replication Failed replication (due to domain controller or network connectivity
problems)
Slow replication
Replication topology invalid/incomplete (lacks transitive
closure/consistency)
Replication using excessive network bandwidth
Too many properties being dropped during replication
Update Sequence Number (USN) update failures
Other miscellaneous replication-related failure events
GC Slow or failed GC query responses
GC replication failures
DNS Missing or incorrect SRV records for domain controllers
Slow or failed DNS query responses
DNS server zone file update failures
Operation masters (FSMOs) Inaccessibility of one or more operation master (FSMO) servers
Forest or domain-centric operation master roles not consistent
across domain controllers within domain/forest
Slow or failed role master responses
Miscellaneous problems Low-level network connectivity problems
TCP/IP routing problems
DHCP IP address allocation pool shortages
WINS server query or replication failures (for legacy NetBIOS
systems and applications)
Naming context lost + found items exist
Application or service failures or performance problems
Table 1.2: Common problems in AD-based Win2K networks.
Chapter 1

26
Change Monitoring and Auditing
In addition to monitoring and troubleshooting problems within the Windows network
infrastructure, another distinct advantage of monitoring software is the ability to monitor and
audit changes made to the AD database. In many organizations, there may be dozens or even
hundreds of administrators making daily changes to AD. In order to manage the potential chaos
this situation presents, its essential that a system be in place to identify all recent changes made
to objects within the directory, and to be able to ascertain who did whatand when. Examples of
the types of changes that you might want to track include changes to the AD schema, OUs,
contacts, computers, and printers as well as directory recovery actions taken by administrators
(for example, a site administration restoring AD on a local domain controller). In todays
security-sensitive environments, this form of change management and auditing may even be a
regulatory requirement.
One problem faced by administrators is Windows relatively poor built-in monitoring and
auditing tools, which make it difficult to assemble a cohesive change management and auditing
solution. Commercial toolsincluding those from Microsoft as well as third-party tools from
companies such as NetPro, NetIQ, Winternals Software, and morehelp to fill the gap left by
Windows built-in capabilities, offering varying features to capture, log, and audit changes that
occur within the directory.
Problem Resolution, Automation, and Alerting
Monitoring and troubleshooting critical network infrastructure components is an important
starting point, but it is by no means the only proactive measure that you can take to increase the
availability of your network. Good network monitoring software provides a wide assortment of
alerting options, such as console alerts, network pop-up messages, event log entries, email alerts,
pager notifications, and Simple Network Management Protocol (SNMP) traps.
In addition to providing problem identification and alerting features, many third-party products
offer automatic problem resolution features. For example, it is possible to configure many
products to take specific corrective actions when a problem is detected, such as restarting a
particular service when it is found to be unresponsive. Many tools use scripting and/or the ability
to call external utilities to accomplish these tasks. The most comprehensive utilities base their
decisions on rule sets derived from an internal database and/or intelligent escalation routines that
emulate what an administrator might do. For example, you might configure a system such that on
the first failure of a given service, that service is restarted; the computer is restarted in the event
that the service restart fails; a different machine is promoted to replace that system in the event
that the computer restart attempt fails, and so on.
Chapter 1

27
Other Considerations
There are several considerations you should keep in mind when creating a Windows network
monitoring and troubleshooting solution. One is the overall architecture of the application(s)
being used in the solution. Its important to understand how the product collects its data and what
impact this collection will have on your network and servers. For example:
Does the product employ local agents to gather metrics or does it use remote queries?
Do throttling features exist to control network bandwidth and system resource usage?
Is there a machine/site/domain hierarchy that allows data to be passed to the central
collection database in an efficient manner?
Does the product provide Web-based management?
All of these questions are important because the answers can have a significant impact on your
network environment and your overall satisfaction with the product.
Another differentiating feature about network monitoring software packages is whether they
provide a support knowledge base of common problems and solutions. This kind of knowledge is
invaluable from both a technical and financial standpoint because it serves to reduce the learning
curve of the supporting IT staff as well as the amount of time and money administrators must
expend researching and resolving problems. Some utilities augment this feature by allowing
administrators to add their own experiences to the knowledge base or a problem tracking and
resolution database, thereby leveraging internal IT staff expertise and creating a comprehensive
problem resolution system.
Organizations facing regulatory compliance issues may also seek software that provides specific
functionality for their specific regulatory issues. For example, tools providing real-time change
auditing and efficient, securable logs and databases may be more useful than tools that provide
batch notification of changes, simple text files instead of a robust database, or easily manipulated
logs that are subject to untraceable tampering. A final feature provided by some applications, and
one that may be of interest to IT shops engaged in SLAs, is the ability to generate alerts and
reports that address exceptions to, or compliance with, SLA obligations.
Summary
Although AD represents a quantum leap forward in the NT product line, it also introduces new
levels of network infrastructure complexity that must be properly managed in order to maintain
an efficient and highly available network. Real-time, proactive monitoring and management of
AD and other critical services is an essential part of managing Windows-based networks. In this
chapter, we discussed the most important features and components of Windows and AD, their
roles within the enterprise, differences between managing NT 4.0-based networks and Win2K or
WS2K3 AD-based networks, and some of the basic metrics and statistics that modern Windows
network administrators need to watch to help them ensure high availability on their networks. In
the remaining chapters of this guide, well drill down and explore each of the vital areas of AD
and Windows networks in detail, providing the information, tools, and techniques youll need to
employ to maintain a healthy and highly available Windows network.
Chapter 2

28
Chapter 2: Designing an Effective Active Directory
The main function of AD is to allow the network resources for Windows to be identified and
accessed. AD accomplishes this goal by providing a single namespace where users and
applications can go to register and gain access to the information they need. For example, a file
server can list available shared folders in AD, and a print server can list available shared printers.
In this way, AD acts as a sort of Yellow Pages of available resources and services; thus, it is
referred to as a directory. AD can be set up and designed in many ways to meet the needs of
users and administrators. Its your job as an administrator to properly set up and design your AD
for maximum efficiency.
The best way to troubleshoot AD problems is to avoid problems in the first place. To do so, you
need to start with an effective design. The design of AD not only includes the layout of the
forests, trees, domains, and organizational units (OUs) but also the site and site links that
represent the physical network.
In this chapter, Ill give you a solid understanding of how to design AD for your environment
and network. Because the information in AD can be distributed across the network, there may be
unique aspects of your design and implementation that apply only to your site. Regardless of
these customizations, my goal is to give you enough information to ensure that the design serves
the needs of your users and administrators. Also keep in mind that AD design goals and
techniques have changed over the past few years since AD was introduced. If you already have
an AD environment, reviewing this information may help you make better decisions for future
growth or for design changes. Ill focus on the design features of AD 2003, which is included
with Windows Server 2003 (WS2K3), and point out specific points that are appropriate to a
Win2K environment or to a mixed-version environment (which must typically operate in a
Win2K backward-compatible mode).
ADs Logical and Physical Structures
As I mentioned in Chapter 1, AD has internal structures that can be categorized as logical and
physical. These structures are the building blocks youll use to design and build your AD service.
Your challenge is to understand each building block and use it to build an efficient AD. The
concepts behind these structures are sometimes complex, but understanding them and using them
correctly are the keys to a good design.
Chapter 2

29
Logical Structures
Table 2.1 provides a list of logical structures used in AD.
Logical Structure Description
Namespace AD is a namespace because it resolves an objects name to the object
itself
Naming context Represents a contiguous subtree of AD
Organizational Unit A container object that allows you to organize your objects and resources
Domain A partition in AD that provides a place to group together users, groups,
computers, printers, servers, and other resources
Tree A grouping of domains that have a parent-child relationship with one
another
Forest A collection of one or more trees
Trust relationship A logical connection between two domains that forms one administrative
unit
Global catalog A central source for AD queries for users and other objects
Table 2.1: The logical structures of AD, which are used to design and build the object hierarchy.
Two important logical structures that you need understand to design an AD are the namespace
and naming context. Although these two concepts seem similar, theyre actually different. To
help you understand how they differ, Ill give you a quick overview of each. These structures are
also discussed throughout the chapter.
Namespace
Another term for a directory is namespace. A namespace refers to a logical space in which you
can uniquely resolve a given name to a specific object in the directory. AD is a namespace
because it resolves a name to the object name and the set of domain servers that stores the object
itself. Domain Name System (DNS) is a namespace because it translates easy-to-remember
names (such as www.company.com) into an IP number address (for example, 124.177.212.34).
AD depends on DNS and the DNS-type namespace that names and represents the domains in the
forest. Its important to design your domain tree in a DNS-friendly way and to provide clients with
reliable DNS services. Although AD uses DNS to create its structure, DNS and AD are totally
separate namespaces.
One way to think about a namespace in non-technical terms is to compare it with a phone book.
The phone book for Las Vegas, Nevada is only capable of resolving phone numbers for names in
the Las Vegas area. In other words, you cant use it to look up a phone number for New York
City. Therefore, the namespace of the directory is said to be Las Vegas. If you wanted to look up
phone numbers in New York, you would need to obtain a directory for that namespace.
Chapter 2

30
Naming Context
The naming context represents a contiguous subtree of AD in which a given name is resolved to
an object. If you look at the internal layout of AD, you see a structure that looks similar to a tree
with branches. If you expand the tree, you see the containers, the objects that reside in them, and
the attributes associated with the objects. In AD, a single domain controller always holds at least
three naming contexts.
DomainContains the object and attribute information for the domain of which the
domain controller is a member
ConfigurationContains the rules for creating the objects that define the logical and
physical structure of the AD forest
SchemaContains the rules for creating new objects and attributes.
Physical Structures
In addition to the logical structures in AD, several physical structures help you implement the
logical structures on your network. Table 2.2 describes these physical structures.
Physical Structure Description
Object and attributes An object is defined by the set of attributes or characteristics assigned
to it. Objects include users, printers, servers, groups, computers, and
security policies.
Domain controller A domain controller is a network server that hosts the AD service in a
domain. Many computers can belong to a domain without being a
domain controller, but only domain controllers actually run the software
that makes AD operate. All members of a domain must contact a
domain controller in order to work with the domain.
Directory server role A server that takes the role of Flexible Single Master Operation
(FSMO). Directory server roles are single-master servers that perform
special roles for AD, such as managing domains, managing schemas,
and supporting down-level clients (Windows NT clients, for example).
Site A location on the physical network that contains AD servers. A site is
defined as one or more well-connected Transmission Control
Protocol/Internet Protocol (TCP/IP) subnets.
Global Catalog (GC) server Stores the GC information for AD.
Table 2.2: The physical structures of AD, which are used to implement the logical directory structures on the
network
Chapter 2
Designing AD
Your primary objective in designing AD is to build a system that reflects the network resources
in your company. You need to arrange the forest and trees to reflect the location and placement
of your network resources. You need to design the domains and OUs to implement an
administrative and security structure for both users and administrators. When designing the
layout of AD, you also need to design the users groups and security policies as well as the
administrative methods that will be used.
From the list of logical and physical structures that you have to work with, four structures are
critical to the design of AD: forests and trees, domains, OUs, and sites. The process of designing
and implementing each of these four structures builds on the previous one. Implementing these
structures properly is crucial to a successful design. Design your AD structure in the following
order:
Design the forest and trees
Design the domains for each tree
Design the OUs for each domain
Design the sites for the forest and domains
In the next four sections, Ill describe how to design each of these main structures.
Designing the Forest and Trees
A forest is a collection of one or more trees. A forest can also be a set of domain trees that
doesnt form a common naming context. For example, a forest can contain a domain named
braincore.net and a domain named netpro.comtwo domains with different namespaces. The
trees in a forest share the same directory schema and configuration but dont need to share the
same namespace. Figure 2.1 illustrates how two companies named company1.com and
company2.com form a single forest.

Figure 2.1: Two organizations named company1.com and company2.com can form a forest in AD.

31
Chapter 2

32
The forest serves two main purposes. First, it simplifies workstation interaction with AD because
it provides a GC through which the client can perform all searches. Second, the forest simplifies
administration and management of multiple trees and domains. A forest has the following key
characteristics and components:
Global schemaThe directory schema for the forest is a global schema, meaning that the
schema is exactly the same for each domain controller in the forest. The schema exists as
a naming context and is replicated to every domain controller. The schema defines the
object classes and the attributes of object classes. In other words, every domain within the
same forest will share the same schema, giving them all access to the same classes and
attributes. This feature is especially important if you plan to deploy schema-altering
applications such as Microsoft Exchange Server, because every domain in the forest will
be updated to have the new Exchange classes and attributeseven if only one of those
domains will actually contain Exchange servers.
Global configuration containerThe configuration container exists as a naming context
that is replicated to every domain controller in the forest. Thus, its exactly the same
across the domain controllers in the forest. The configuration container contains the
information that defines the structure of the forest. This information includes the
domains, trust relationships, sites, site links, and the schema. By replicating the
configuration container on every domain controller, each domain controller can reliably
determine the structure of the forest, allowing it to replicate to the other domain
controllers.
Complete trustAD automatically creates bi-directional transitive trust relationships
among all domains in a forest. This relationship allows the security principals, such as
users and groups of users, to authenticate from any computer in the forest. However, such
is only the case if the users access rights have been set up correctly. This concept is
important: Trusts do not instantly confer access permissions. For example, a user in
Domain A cannot immediately access resources in Domain B just because the two
domains are in the same forest. The forest simply makes such access possible, enabling
an administrator to select the Domain A users account when assigning permissions to the
resources in Domain B.
GCThe GC contains a copy of every object from every domain in the forest. However,
it only stores a select set of attributes from the objects; that subset is referred to as the
universally interesting information for the objects. By default, the GC isnt placed on
every domain controller in the forest; instead, you determine which domain controllers
should hold a copy. The purpose of the GC is to provide a sort of cross-domain lookup
service.
To re-use the phone book analogy, imagine that youre holding a Las Vegas phone book
and need to look up a number for a New York resident. The phone book you have might
contain a GC section, which lists a number for New York Directory Assistance. This
reference allows you to contact a directory in that other, New York namespace, to handle
your query. More specifically, the GC as implemented in AD will list each name
available in New York, and refer you to a New York directory for the number. In other
words, the GC is aware of every object in the forest and knows where to go to find more
information about each object.
Chapter 2

33
The other attribute shared across the entire forest is the built-in Enterprise Admins group.
Members of this group have the highest possible level of administrative control over every
domain within the forest. Whoever belongs to this group, then, must be trusted by every domain
within the forest to manage the entire forest and all of its domains. There are occasions, however,
in which no one group of users can be given this trust, in which case two or more forests will be
necessary.
For example, consider an organization that has just acquired another company. If the two forests
are merged into a single forest, all the users can view the entire AD. However, the forests might
not be merged because the two autonomous administrative groups might not agree on how to
manage the forest. The winner of this dispute depends on your priority: Do your users have a
higher priority than your administrators?
If the administrators win, the users inherit two forests and no longer have a single, consistent
view of AD. Each administrative group manages its own forest independently. This scenario is
common and is the reason that the forest is often referred to as ADs ultimate security
boundarybecause you can create a strict border between the two forests but cannot create a
border within a forest because of the built-in Enterprise Admins group.
The answer to the administrator vs. user priority question also depends on which type of
organization your company is. If it isnt important for the users to have a consistent view of AD,
it might be appropriate to have multiple forests with separate administrators. For example,
consider an application service provider (ASP) company, which hosts AD services on behalf of
other companies. The users from those companies have no reason to view the host companys
information. In addition, each administrative group wants its independence.
WS2K3 introduces a new capability called the forest trust. As with the domain trusts present
within a forest, a forest trust makes it possible for accounts in one trusted forest to be granted
access to resources in another, trusting forest. However, unlike the automatic, two-way,
transitive trusts within a domain tree or forest, inter-forest trusts must be manually created and
are one-way. In other words, the administrators in Forest A could decide to grant access to Forest
B user accounts, but the reverse will not be true unless the Forest B administrators implement
their own trust to Forest A. This inter-forest trust capability is only possible between forests
running at the WS2K3 functional level, which means all domain controllers within the forest
must be running WS2K3 and all domains within the forest must be running at the WS2K3
functional level as well.
The Types of Trusts
Remember that WS2K3 offers a variety of trust relationships. There are, for example, the automatic, two-
way, transitive trusts that exist between parent and child domains in a domain tree. There are also one-
way, non-transitive external trusts that you can create between, for example, a WS2K3 domain and an
NT domain. Forest trusts are similar to these external trusts, although they are WS2K3-specific. You can
also establish external trusts with UNIX Kerberos realms, a domain-like structure that exists in UNIX
systems, by using the Kerberos authentication protocol.
Chapter 2

34
Determining the Number of Forests
When determining the number of forests for your company, consider the requirements of the
organization itself. In smaller, centrally managed organizations, you typically need one forest.
However, if the company is large and has multiple locations in one or multiple countries, you
may need multiple forests. To properly determine the number of forests for your company, you
need to understand the maintenance and overhead of having one forest compared with having
multiple forests.
An environment with a single forest is simple to create and maintain. All users view one AD by
using the GC. Maintaining a single forest is easy because you need to apply configuration
changes only once to affect all the domains in the forest. For example, when you add a domain to
the forest, all the trust relationships are set up automatically. In addition, the new domain
receives any additional changes made to the forest.
When deciding on the number of forests you need, remember that a forest has shared elements:
the schema, configuration container, and GC. Thus, all the administrators need to agree on the
content and management of forests and their elements. Managing these elements becomes more
complicated when you add a forest because it incurs a management cost. The following brief list
highlights many of the management issues surrounding multiple forests:
Each additional forest must contain at least one domain, domain controller, and someone
to manage the forest. Practically, you should have at least two domain controllers for
redundancy.
Each additional forest creates a schema. Maintaining consistency among schemas is
difficult and creates overhead.
Each additional forest creates a configuration container. Maintaining consistency among
configuration containers when the network configuration changes is difficult and creates
overhead.
If you want user access among forests, you must create and maintain explicit one-way
trusts for every relationship you establish. If every domain and forest is WS2K3, you can
create one trust between the forests; otherwise, you must create direct domain-to-domain
trusts, which can result in a large number of trust relationships that must be monitored.
Users who want access to resources outside of their forest need to make explicit queries;
this task is difficult for the ordinary user because the syntax for doing so isnt
straightforward and the Windows user interface (UI) doesnt make this function readily
accessible. Ideally, then, users should be able find the vast majority of the resources they
need within their own forest.
Any synchronization of components among multiple forests must be performed manually
or by using a metadirectory service or other synchronization solution.
Users cannot easily access the network resources contained in other forests.
Chapter 2

35
One situation in which you might consider managing multiple forests occurs when two organizations
merge or participate in a joint venture. This merger puts the administration of your network into the
hands of two autonomous groups. For this reason, multiple forests are typically more costly to
manage. To reduce this cost, organizations such as partnerships and conglomerates need to form a
central group that can drive the administrative process. In contrast, in short-lived organizations such
as joint ventures, it might not be realistic to expect administrators from each organization to
collaborate on forest administration.
There is another good example of a situation in which multiple forests may be required. Many
enterprise organizations elect to maintain separate, parallel AD forests for testing purposes. Other
organizations maintain multiple forests because they have a disjointed organizational structure with
no common infrastructure among business units. Although youll certainly want to keep your network
and AD design as simple as possible, your forest structure should follow the organizational,
administrative, and geographical structure of your organization.
Setting Up and Managing Multiple Forests
Setting up and managing two forests might be necessary if two organizations in a company dont
trust one another or cannot agree on administrative policies. For example, suppose that a
company has two locations in cities in different countriesNew York and London. Each
location has its own administrative group, which needs to manage its network resources
according to its own policies. In this case, two different forests can be used to separate the
administrative requirements. The requirements of such a situation are the most common reason
for having multiple forestsand you need to understand that it is a purely business, or political,
reason; there are very few technical reasons to have multiple forests.
In other situations, such as creating a testing environment separate from the production
environment, your company might have multiple forests, but you want to have a central
administrative group. To set up central management of multiple forests, you need to add
administrators to the Enterprise and Schema Administration groups of each forest. Because there
is only one Enterprise and Schema Administration group per forest, you must agree on a central
group of administrators who can be members of these groups.
As mentioned previously, its difficult to manage user access between two or more forests. The
simplest method in any Win2K or mixed-version forest is to create explicit one-way trusts
among the domains that must trust one another. The one-way trust allows access only among the
domains in the direction in which the trust is set up. Figure 2.2 illustrates this approach of
connecting forests.
Chapter 2

Figure 2.2: Two forests can allow user access between domains by establishing explicit one-way trusts. Only
the domains connected by the trusts can allow access between the forests.
Explicit one-way trusts arent transitive; the one-way trusts in Win2K are the same as the one-
way trusts that exist in NT. Creating one-way trusts among multiple forests or trees can be
complicated, so its important to keep it simple by limiting the domains that trust one another.
In WS2K3, as Ive mentioned, you have the option to create inter-forest trusts. This setup allows
all domains in the trusted forest to potentially access resources in all domains of the trusting
forest. This feature greatly simplifies access management across forest boundaries, although only
forests running at the WS2K3 functional level have this capability. Thus, every domain
controller in every domain must be running WS2K3, every domain must have been raised to the
WS2K3 functional level, and both forests must have been raised to the WS2K3 functional level.
If so much as one Win2K domain controller exists in a single domain in either forest, inter-forest
trusts are not an option.
Determining the Number of Trees
A tree is simply a grouping of domains with parent-child relationships. The domains that form a
tree are arranged hierarchically and share a common and contiguous namespace. Trees can be
viewed one of two ways. The first view is the trust relationships among domains. The second
view is of the namespace of the domain trees (see Figure 2.3).

36
Chapter 2

Figure 2.3: The namespace of the domain tree shows the hierarchical structure of the tree.
In a single forest, in which all domains trust one another, the tree relationship is defined by the
namespace that is necessary to support the domain structure. For example, the root domain called
company.commight have two subdomains (or child domains) named seattle.company.comand
chicago.company.com. The relationship between the root domain and the two child domains is
what forms the tree, or namespace.
In the previous section, I emphasized that multiple forests in an organization are generally not
recommended if there is a way to avoid it. However, there are situations in which multiple trees
are appropriate or even recommended. For one, multiple trees allow you to have multiple
namespaces that coexist in a single directory. Multiple trees give you additional levels of
separation of the namespacessomething that domains dont provide. Although multiple trees
work well in most situations, I recommend that you start by creating one tree until the
circumstances arise that call for more. For example, if your company has a domain named
company.com, then launches a subsidiary named corporation.com, it might make sense to have
both domain trees in the same forest. Doing so would provide you with the necessary
namespaces, while maintaining the convenience of a single forests central administrative
structure, common schema, and so forth.
You might be wondering if there are any extraordinary benefits to having multiple trees. For
example, do multiple trees reduce the replication or synchronization that occurs among domain
servers? The answer is no, because the schema and configuration container are replicated to all
domain controllers in the forest. In addition, the domain partitions are replicated only among the
domain controllers that are in the domain. Having multiple trees doesnt reduce replication.
Likewise, you may be wondering whether multiple trees cause any problems. For example, does
having multiple trees require you to establish and maintain explicit one-way trust relationships?
Again, the answer is no because the transitive trust relationships are automatically set up among
all domains in the forest. This trust includes all domains that are in separate trees but in the same
forest.

37
Chapter 2
Designing the Domains
The next task in planning AD is creating and designing the domains. A domain gives you a place
to group users, groups, computers, printers, servers, and other resources that belong together. In
addition, a domain is a security boundary for these objects, and it defines the set of information
that is replicated among domain controllers. The domain in AD works like the domain that exists
in NT.
A domain is a physical piece of AD that contains the object information. Figure 2.4 shows a
domain structure with its contents of network resources.

Figure 2.4: The domain structure is a piece of AD. It contains the users, groups, computers, printers, servers,
and other resources.
The purpose of domains is to logically partition the overall forest. Most large implementations of
AD need to divide the forest into smaller pieces. Domains enable you to partition AD into
smaller, more manageable units that you can distribute across your network servers.
Domains are the basic building blocks of AD. As youve seen, they can be connected to form
trees and forests; domains are connected by trust relationships, which are automatically
established and maintained within the forest. These trusts allow the users of one domain to
access the information contained in the other domains. When multiple domains are connected by
trust relationships and share a common schema, you have a domain tree. Every AD installation
consists of at least one domain tree, even if that tree has only a root domain.

38
Chapter 2

39
Its your role as an administrator to decide the structure of domains and which objects, attributes,
groups, and computers are created. The design of a domain includes a determination of DNS
naming, security policies, administrative rights, and how replication will be handled. When you
design domains, follow these steps:
Determine the number of domains
Choose a forest root domain
Assign a DNS name to each domain
Partition the forest
Place the domain controllers that will be used for fault tolerance and high network
availability
Determine the explicit trust relationships that need to be established, if any
Determining the Number of Domains
I recommend that you start with one domain in your environmenteven if there are two or more
physical locations; AD has a separate way of understanding your physical network structure, and
domains arent necessarily intended to reflect that physical structure. A single-domain design
keeps the layout of your domain simple and easy to maintain, and you can then add other
domains as needed. The mistake some people make is to initially create many domains, then not
know what to do with them. One domain will be adequate for many companies, especially
smaller ones.
Although one domain will work in most circumstances, other circumstances necessitate having
more than one domain for an entire organization. The following list highlights such situations;
you must decide which of these fit your needs:
Administrative rightsIf your organization has multiple administrative groups that want
some level of autonomy, you might need to create additional domains and give each
group its individual rights. For example, if two companies merge together, one group
might need to operate and maintain autonomous activities. Understand, however, that the
forest-wide Enterprise Admins group can always control every domain within the forest.
If one administrative group within your company needs absolute and total control over
their resources, only a separate forest will provide that level of autonomy.
International settingIf your organization is international, you might need to create
additional domains to support other languages. (Administrators, users, and others may
need to access AD in their first language, and the schema contains language-specific
attribute display names.)
Chapter 2

40
Replication trafficBecause the AD database can be distributed, you might want to
create additional domains to hold the distributed partitions. The need to create additional
domains typically arises when you have a single domain trying to replicate across wide
area network (WAN) links. If the replication is too slow, you can alleviate the problem
by splitting the domain into two. You can then place the two domains on each side of the
WAN so that they can be closest to the users. Understand, however, that individual
domains still replicate with one another. Specifically, the GC serverswhich must exist
in each domainreplicate information about every domain in the forest. Thus, placing
domains on either side of a WAN link will reduce replication traffic across that link, but
will by no means eliminate it.
Account security settingsAccount security settings apply to the entire domain. Account
security settings include password length and expiration period, account lockout and
intruder detection, and Kerberos ticket policy. These settings cannot be changed in the
domain for individual OUs or groups. If you need to have unique settings, you will need
to create another domain.
Preserve an existing NT domainIf your company already has an existing NT domain,
you might want to keep it instead of consolidating it into an AD domain. This
requirement could produce more domains than planned.
Determining the number of domains for your organization is an individual effort. No one can tell
you definitively how many domains to have and how to split them without knowing more about
your companys organization and network. However, using these simple guidelines, you can
establish parameters that enable you to effectively design domains and determine the appropriate
number for your company. Be prepared to recognize that many of the reasons for having multiple
domainslike the reasons for having multiple forestsare primarily political or business-related
in nature, and not technical. Sometimes a single domain makes sense from almost every possible
technical standpoint (unlike NT domains, which had a technical limit on the number of objects
that could reside in the domain, for example), but multiple domains are still required for business
or political reasons.
Choosing a Forest Root Domain
The first domain that you create becomes the forest root domain (or root domain), which is the
top of the forest and the top of the first tree. The forest root domain is extremely important
because it determines the beginning of the namespace and establishes the forest. Because the AD
forest is established with the first domain, you need to make sure that the name of the root
domain matches the top level in the namespace. For example, root domains are domains with
names such as company.com and enterprise.com. These domain names are the roots of the DNS
structures and the root of AD. Any subsequent domains you create or add to the tree form the
tree hierarchy.
Chapter 2

41
The first domain you create in an AD forest contains two forest-wide groups that are important to
administering the forest: the Enterprise Administrators, which is often referred to as Enterprise
Admins, group and the Schema Administrators, or Schema Admins, group. Containing these two
groups makes the root domain special. You cannot move or re-create these groups in another
domain. Likewise, you cannot move, rename (at least not easily), or reinstall the root domain. In
addition to these groups, the root domain contains the configuration container, or naming
context, which also includes the schema naming context.
After you install the root domain, I recommend that you back up the domain often and do
everything you can to protect it. For example, if all the servers holding a copy of the root domain
are lost in a catastrophic event and none of them can be restored, the root domain is permanently
lost. The reason for this loss is that the permissions in the Enterprise Administrator and Schema
Administrator groups are also lost. There is no method for reinstalling or recovering the root
domain and its groups in the forest other than completely backing up and restoring it.
Always have at least two domain controllers in every domain, and always have at least two
geographic locations, if possible, containing domain controllers for each domain. If you have two
offices, try to have domain controllers from your root domain in every office. This setup might not be
possible in every situation due to replication traffic and availability of technical personnel at each
location, but its a worthy goal because it helps reduce the likelihood that a single catastrophic event
will destroy the root domain. At the very least, ensure that the root domain is backed up frequently
and that copies of the backup are maintained offsite.
Using a Dedicated Root Domain
As I described earlier, the first domain you create in AD becomes the forest root domain. For
smaller implementations of AD, you might only need to create the root domain, nothing more.
For more information about determining the number of domains, see Determining the Number of
Domains earlier in this chapter.
For a larger implementation with multiple locations around the world, however, youll probably
want to use a dedicated root domain. A dedicated root domain is a root domain that is kept small,
with only a few user account objects. Keeping the root domain small allows you to replicate it to
other locations at low cost (that is, with little impact on network usage and bandwidth). Figure
2.5 illustrates how you can replicate a dedicated root domain to the other locations on your
network.
Chapter 2

Figure 2.5: A dedicated root domain is small enough to efficiently replicate copies to the other locations on
your network.
A dedicated root domain focuses on the overall operations, administration, and management of
AD. There are at least two advantages to using a dedicated root domain in a larger
implementation of AD:
By keeping the user and printer objects out of the root domain, you enhance security by
restricting access to only a few administrators.
By keeping the root domain small, you can replicate it to other domain controllers on the
network at distant geographic locations. This approach helps increase the availability of
the network.
Because domain administrators can access and change the contents of the Enterprise
Administrators and Schema Administrators groups, having a dedicated root domain limits
normal access. Membership in these built-in groups should only be given to the enterprise
administrators, and they should only access the domain when doing official maintenance. In
addition, membership in the Domain Administrators group of the root domain should be granted
only to the enterprise administrators. Taking these steps allows you to avoid any accidental
changes to the root domain. You should also create a regular user account for each of your
administrators so that they dont carry administrative privileges while doing regular work.
As I mentioned earlier, always replicate the root domain to multiple servers in an effort to
provide fault tolerance for this domain. Because a dedicated root domain is small (no user or
printer objects), it can be replicated across the network more quickly and easily. In addition to
replicating the root domain across the local area network (LAN), you can replicate the root
domain across the WAN to reduce the trust-traversal traffic among trees.

42
Chapter 2

43

Trust-traversal traffic can be complicated to understand. Essentially, anytime a user accesses
resources outside of his or her domain, the user (or the users client computer) must contact a
domain controller within the domain that contains the resources. If a direct trust does not exist
between the domains, additional domain controllers may need to be contacted.
Having a local domain controller for trusting domains helps reduce this trust-traversal traffic across
WAN links. However, locating a domain controller in a site may increase replication traffic across the
WAN link, which can, in some cases, be exponentially higher than trust traffic. Youll need to evaluate
your circumstances to decide on the best approach for your organization.
Assigning a DNS Name to Each Domain
After youve determined the number of domains and installed the root domain, you need to
determine the DNS names for each domain. DNS is a globally recognized, industry-standard
system for naming computers and network services that are organized in a hierarchy. AD clients
make queries to DNS in an attempt to locate and log on to domains and domain controllers.
Network users are better at remembering name-based addresses, such as www.company.com,
than they are at remembering number-based addresses, such as 124.177.212.34. DNS translates
an easy-to-remember name address (www.company.com) into a number address
(124.177.212.34).
As Ive mentioned, the domain is identified by a DNS name. You use DNS to locate the physical
domain controller that holds the objects and attributes in the domain. DNS names are
hierarchical (like AD domains). In fact, the DNS name for a domain indicates the position of the
domain in the hierarchy. For example, in the domain name company.com, the DNS name tells us
that the domain must be at the top of the forest and is the root domain. Another example is
marketing.chicago.company.com. From this domain name, we know that the domain is the
marketing departments domain in the Chicago location of the company. The domain is two
levels from the root domain, or top of the tree. The Chicago domain is a child domain of the root
domain, or company, and the marketing domain is a child domain under Chicago.
When you create DNS names for the domains in AD, I recommend that you follow these
guidelines:
Use an Internet-registered name for the top-level domain
Use Internet standard characters
Use locations to name child domains
Never use the same name twice
Chapter 2

44
Using an Internet-Registered Name for the Top-Level Domain
When you name your top-level domain, I recommend that you use only a DNS name that has
been registered on the Internet and is thus globally unique. For example, realtimepublishers.com
is a top-level domain name and is registered with the Internet Corporation for Assigned Names
and Numbers (ICANN). You dont need to register the names of underlying domains because
they fall under the control and jurisdiction of the top-level domain owner/registrant. For
example, the domain name research.realtimepublishers.com doesnt need to be registered.
You dont need to use an Internet-registered name; AD itself doesnt care. However, if you name
your domain Microsoft.com, your users will have difficulty accessing the real Microsoft.com. If
you must use a non-registered domain name, use one with the special pri top-level domain
name, as in company.pri. Domain names ending in pri cannot be registered on the Internet, so
youre guaranteed not to conflict.
You may not be responsible for your companys Internet access. In that case, its important that you
coordinate your AD naming efforts with the person or group that is responsible for that access to
ensure that youre not creating any unmanaged name resolution problems. For exampling, choosing
to use your companys registered Internet domain name requires additional internal and external
configuration steps to ensure uninterrupted name resolution for your domain clients and other
network clients.
Because you choose to use an Internet-registered name, however, does not mean you must
expose that name on the Internet. For example, you might register companyinternal.org as your
internal DNS name for ADs use, and use company.com on the Internet. Doing so will help
avoid exposing your internal DNS infrastructure to the Internet. You can also use something
called a split-brain DNS. In this technique, you would use a single registered namesay,
company.comfor both your internal AD domain name and your external Internet presence. An
external DNS server, connected to the Internet, would resolve names for public hosts in your
domain, such as www. A separate internal DNS server would resolve internal host names and
support AD; it would also contain static records for external names such as www. This
technique allows the same domain name to serve both internal and external uses, while ensuring
that Internet users have no access to your internal DNS infrastructure.
Using Internet Standard Characters
When you assign DNS names, youre restricted to using only Internet standard characters to
ensure compatibility with AD and the Internet. The basic standards for naming are as follows:
Domain names contain only letters, numbers, and hyphens (-). The underscore character
(_)is specifically not allowed, although Microsofts DNS implementation will accept it.
Domain names cannot begin or end with a hyphen.
The domain names of .com, .net, and .org cannot exceed 67 characters.
Relative domain names (that is, the components between the dots in a fully qualified
domain nameFQDN) cannot exceed 22 characters apiece (this limitation doesnt
include any extensions).
Domain names arent case sensitive (although they are traditionally typed in lowercase).
Domain names cannot include spaces.
Chapter 2
Using Locations to Name Child Domains
When you determine the name of the child domains, I recommend that you use a name that
describes the administrative layer that the domain represents. For example, if youre creating a
domain so that individuals in your companys research division will have more direct control
over their own resources, name the domain research. A domain intended for a European
subsidiary might be named europe, and so forth. This naming process applies to the first layer
of child domains that you create under the root domain. For example, the first layer of domains
that you create under the root might have names based on physical locations, if thats how it
makes sense to divide the administrative responsibilities in the forest. Figure 2.6 portrays the first
layer of domain names, representing the physical locations on a network.

Figure 2.6: The first layer of domains directly under the root domain is named after the physical locations on
the network.
One strong recommendation for sticking with a geographic naming scheme is that other,
organizationally based naming schemes are prone to constant change. For example, the research
division might be absorbed into a larger operations division, and it wouldnt make sense to have
the domain named research anymore. However, its unlikely that New York, for example, will
be changing its name. The AD domain hierarchy isnt nearly as fluid or adaptable as the business
itself. Once you create and name domains, you cannot move or rename them easily. In addition,
you cannot move or rename the root domain.
WS2K3 provides the ability to rename domains, which is a new feature. However, renaming domains
is a complex process and there is no guarantee that the rename wont break other applications that
rely on AD. For planning purposes, work under the assumption that domains cant be renamed.
Using locations to name child domains is more flexible because physical locations on a network
seldom change. The organization at the specific site may change but not the physical location
itself. This design allows the tree to be more flexible to everyday changes. However, if the
physical location is changed or removed, the resources are moved (including the physical
resources, such as domain controllers, printers, and other equipment supporting the site).

45
Chapter 2

46
If your company is smaller and contained in one physical location, you could name domains after
the company or organization. These domains then hold all the objects and attributes for your
company. This design is easy and efficient. However, if your company has multiple physical
locations with network resources spread across them, youll want to create a second layer of
domains (under the root domain), and give the domains location names. The organizational
structures of business units, divisions, and departments will then be placed under each of these
location domains.
The caveat you knew was coming: Nobody can tell you the perfect domain naming scheme
without knowing more about your organization. It might very well be that an organizational-
based naming scheme makes absolute sense for your company. For example, some companies
have many divisions, all of whom share office space in various cities. However, these divisions
are independently managed and maintain their own network resources. In such a case, it makes
the most sense to name the domains after the divisions rather than the locations.
Never Using the Same Name Twice
I recommend that you never use the same DNS name twice, even if the names are used on
different networks. This simple guideline will help eliminate any confusion down the road. For
example, lets say you decide to use the domain name engineering.company.com. Dont use this
name for any other domain, even if the domain is on a different network. A client may connect to
both networks and query engineering.company.com. Depending on the layout of the network, the
client may locate the wrong domain in the wrong forest.
Dividing the Forest
In larger organizations, the implementation of AD can become quite large. As it grows, I
recommend that you break it into smaller pieces, which Ill call a partition. A partition, in this
context, is a domain or portion of the directory tree that extends from the beginning of a branch
(or naming context) to the bottom of the tree.
The term partition can be a confusing one in the world of directory services. AD defines the concept
of a partition as a segment of a particular domain or forest. In WS2K3, not every domain controller
may contain all of the domain database. For example, an AD-integrated DNS zone in WS2K3 might
be included in a partition that is only stored on domain controllers that are also DNS servers.
In the context of this discussion, Im using partition in a somewhat different sense, mainly because
there really isnt a better term to use. In all cases, partition refers to a portion of the directory services,
such as a portion of the forest, a portion of a domain, and so forth.
The domain physically stores the containers, objects, and attributes in that branch. Several rules
control the creation of partitions in AD and how they operate:
The topmost partition is the root domain
Partitions dont overlap (one object cannot be held in two partitions)
The partitions contain all the information for the naming context
Chapter 2
In AD, the basic unit of partitioning is the domain. Thus, when you create your first partition,
youre actually creating a child domain under the root domain. The domains in AD act as
partitions in the database; for example, a child domain helps split up the total user objects
(among other things) that are contained within the directory. Thus, each domain represents a
portion, or partition, in the overall AD database. Partitioning this database increases its
scalability. As you partition AD, you break it into smaller, more manageable pieces that can be
distributed across the domain controllers, or network servers. Figure 2.7 illustrates how you can
divide the AD database into smaller pieces that can be distributed to the domain controllers.

Figure 2.7: You can partition the AD database into smaller pieces, then distribute them among network
servers or domain controllers.
Breaking AD into smaller pieces and distributing them among multiple servers places a smaller
load and less overhead on any one server. This approach also allows you to control the amount
and path of traffic generated to replicate changes among servers. Once you create a partition,
replication occurs among servers that hold copies.
In AD, you can create many partitions at multiple levels in the forest. In addition, copies of the
domain can be distributed to many different servers on the network. Although AD is distributed
using partitions, any user can access the information completely transparently. Users can access
the entire AD database regardless of which server holds which data. Of course, users must have
been granted the proper permissions.
Although a single domain controller may not contain the entire AD database (that is, the entire
forest-wide database), users can still receive whatever information they request. AD queries the
GC on behalf of a user to identify the requested object, then resolves the name to a server
(domain controller) address using DNS. Again, this process is entirely transparent to the user.

47
Chapter 2

48
I want to point out that the proper way to think about AD is in terms of the entire forest. The directory,
or the AD database, contains everything in the entire forest; domains represent a portionor
partitionof that larger forest-wide database. Thinking about databases in terms of a single domain
or even a single domain controller makes it too easy to miss the larger scope of AD. Per-server
databases went away with NetWare 3.x; per-domain databases go away with NT. AD is a larger
database, consisting of many domains.
Similarly, too many partitionsdomainsis something to be avoided. As Ive mentioned previously,
you generally want as few domains as possible to ease both management and operational activities.
There are reasons, which Ive covered, to have multiple domains, but simply creating more domains
to arbitrarily partition the forest isnt one of those reasons.
Placing the Domain Controllers for Fault Tolerance
After youve partitioned AD, you need to decide how to distribute each new domain or partition
across the network servers. The domain controllers are the servers that store the domains and
their distributed copies. One domain controller holds only one copy of an AD partition or domain
unless its a GC. The domain controller stores the objects for the domain or partition to which it
belongs.
The availability of domain information is strictly determined by the availability of the domain
controllers. Its obvious that the domain controllers must be available so that users can log on
and access AD information. For this purpose, never have only one domain controller for any
domain. I recommend that you have at least two domain controllers for each domain to provide
redundancy and fault tolerance for every domain in your organization. Of course, locations with
more users or greater availability needs will have additional domain controllers to meet those
needs.
Determining Trust Relationships
Trust relationships are logical connections that combine two or more domains into one
administrative unit. Trust relationships allow permissions to be associated and passed from one
domain to another. Without some sort of trust among domains, users cannot communicate or
share resources. In this section, Ill describe the advantages of using bi-directional trusts, one-
way trusts, and cross-link trusts.
Using Bi-Directional Transitive Trusts
In AD, trust relationships are automatically established between every domain and its parent
domain in the tree or forest. This setup greatly reduces the overhead of managing trust
relationships. The types of trusts that are created are called bi-directional transitive trusts. The
best way to understand the concept of transitive trusts is to use an example. Figure 2.8 shows bi-
directional trusts being established among all the domains and their child domains.
Chapter 2

Figure 2.8: Each domain has a bi-directional transitive trust relationship between itself and each of its child
domains.
One of the advantages of these new trusts is that theyre automatically established among all
domains; this benefit allows each domain to trust all the other domains in the forest. Another
advantage is that these bi-directional trusts, which are automatically established using Windows
Kerberos security mechanism, are much easier to set up and administer than NTstyle trusts.
Having bi-directional trusts also reduces the total number of trust relationships needed in a tree
or forest. For example, if you tried to accomplish the same thing in NT, you would need to create
two-ways trusts between one domain and every other domain. This setup would increase the total
number of trusts exponentially with the number of domains.
If you have experience with NT domains, you may know something of trust relationships.
However, the trusts in AD differ from NT trusts because AD trusts are transitive. To help you
understand what this means, Ill provide an example. AD transitive trusts work much like a
transitive equation in mathematics. A basic mathematical transitive equation reads as follows:
A=B, B=C, t her ef or e A=C
When applying this transitive concept to trust relationships, you get an understanding of how
transitive trusts work among domains. For example, if Domain A trusts Domain B, and Domain
B trusts Domain C, then Domain A trusts Domain C. Figure 2.9 illustrates this idea. Transitive
trust relationships have been set up between Domain A and Domain B and between Domain B
and Domain C. Thus, Domain A trusts Domain C implicitly.

49
Chapter 2

Figure 2.9: A domain tree viewed in terms of its transitive trust relationships. Because transitive trust
relationships have been set up between Domain A and Domain B and between Domain B and Domain C,
Domain A trusts Domain C implicitly.
In NT, trusts were non-transitive, so they didnt allow this implicit trust to exist. For one domain
to trust another domain, an explicit trust relationship had to be created between them.
When domains are created in an AD forest, bi-directional trust relationships are automatically
established. Because the trust is transitive and bi-directional, no additional trust relationships are
required. The result is that every domain in the forest trusts every other domain. Transitive trusts
greatly reduce your overhead and the need to manually configure the trusts. Because trusts are
automatically set up, users have access to all resources in the forest as long as they have the
proper permissions.
Transitive trusts are a feature of the Kerberos authentication protocol. The protocol is used by
AD and provides distributed authentication and authorization. The parent-child relationship
among domains is only a naming and trust relationship. Thus, the trust honors the authentication
of the trusted domain. However, having all administrative rights in a parent domain doesnt
automatically make you an administrator of a child domain. Policies set in a parent dont
automatically apply to child domains because the trust is in place.
Using One-Way Trusts
One-way trusts arent transitive and are used among domains that arent part of the same forest.
If youre familiar with the one-way trusts in NT, the one-way trusts that exist in newer versions
of Windows are just the same. However, theyre only used in a handful of situations.
First, one-way trusts are often used when new trust relationships must be established among
domains of different forests (when, for example, an inter-forest trust isnt possible). You can use
them among domains to isolate permissions. For example, you can use one-way trusts to allow
access among forests and among the domains of the same tree. Figure 2.10 shows how you can
create a one-way trust between two domains in two different forests. Setting up a one-way trust
allows users to access network resources in the direction of the trust. The actual user rights
depend on the access control lists (ACLs) governing the domains.

50
Chapter 2

Figure 2.10: A one-way trust is established between a domain in Forest 1 and a domain in Forest 2. The trust
allows access to network resources in each domain.
The second use of one-way trusts is to create a relationship from an AD domain to backward-
compatible domains, such as an NT domain. Because NT domains cannot naturally participate in
AD transitive trusts, you must establish a one-way trust to them. You must to manage one-way
trusts manually, so try to limit the number you use.
In both of these situations, you can create two one-way trusts among the domains. However, two
one-way trusts dont equal a bi-directional transitive trust in AD.
A third type of one-way trust is, as Ive mentioned, the inter-forest trust. This type works exactly
like a one-way trust between two domains, except that it establishes trust between every domain
in the respective forests. Again, this type of trust is available only in an environment in which
every domain controller is running WS2K3.
Using Cross-Link Trusts
Cross-link trusts are used to increase performance among domains. Cross-link trust relationships
help increase the speed at which users authenticate among domains. However, cross-link trusts
are needed only between two domains that are both far from the root domain. To completely
understand the need for the cross-link trusts, you first need to understand how user authentication
works in AD.
When a user needs to authenticate to a resource that doesnt reside on its own domain, the client
first must to determine where the resource is and locate it. If the resource isnt in the local
domain, the domain controller will pass back a referral list of other domain controllers that might
have the resource. The workstation then contacts the appropriate servers in the referral list to find
the resource. This process continues until the requested resource is found. This process is often
referred to as chasing referrals and can take time, especially on large or complex AD networks.

51
Chapter 2
Walking up and down the domain tree branches lengthens the time it takes to query each domain
controller and respond to the user. To speed this process, you can establish a cross-link, or
shortcut, trust relationship between two domains. If you decide to use a cross-link trust, I
recommend that you place it between the two domains that are farthest from the root domain.
For example, suppose you have a domain tree that has domains 1, 2, 3, 4, and 5 in one branch
and domains 1, A, B, C, and D in another branch. Domains 5 and D are located farthest from the
root domain (see Figure 2.11).

Figure 2.11: The domain tree has two branches, domains 1, 2, 3, 4, and 5 are one branch, and domains 1, A,
B, C, and D are the second branch. The cross-link trust can be established between domains 5 and D.
Lets say that a user in Domain 5 needs to access a resource in Domain D. To accomplish this
request, the authentication process must traverse up the first branch and down the second branch
while talking to each domain controller. Continuous authentications such as this create a
significant amount of network traffic. To alleviate this problem, you can establish a cross-link
between Domain 5 and Domain D.
The cross-link between Domain 5 and Domain D will serve as an authentication bridge between
the two domains. The result is better authentication performance between the domains.
The need for cross-link trusts is a good reason to keep your domain hierarchy as flat as possible.
Cross-link trusts should only be used when absolutely necessary, and a good design wont require
them.

52
Chapter 2

53
Designing OUs for Each Domain
An OU is a container object that allows you to organize your objects and tie a Group Policy
Object (GPO) to it. Using the OU, you can group similar objects into logical structures in a
domain. OUs can also be nested to build a hierarchy in a domain. This hierarchy of containers is
typically named after divisions, departments, and groups in your company. When youre
designing and creating the hierarchical structure in each domain, its important to understand the
following characteristics of OUs:
OUs can be nestedAn OU can contain other OUs, enabling you to build a hierarchy
inside each domain.
OUs can help delegate administrationYou can delegate administrative tasks to
subordinate administrators by creating subordinate OUs. Using nested OUs, you can fine-
tune the level of control you need.
OUs arent security principalsYou cannot make an OU a member of a group. You
cannot grant users permissions to resources because they reside in a particular OU.
Because OUs are used to delegate administration, they can specify who manages the
resources in the OUs, but they dont indicate the resources a user can access.
OUs can be associated with a GPOA GPO enables you to define configurations for
users and computers in OUs. For example, you can create a desktop policy that every
user in the OU will use.
AD comes with two built-in containers, Users and Computers, that look superficially like OUs but
arent. They cant have GPOs linked to them, for example.
OUs dont need to be viewed by usersIt isnt necessary for you to design OUs with
user navigation in mind. Although users can view the OU structure, this structure isnt an
efficient method for finding resources. The preferred method for users to find resources is
by querying the GC.
Now that you understand a few of the basic characteristics for OUs, consider the following
guidelines for designing an efficient and effective OU structure:
Create OUs to delegate administration
Create OUs to reflect your companys organization
Create OUs for Group Policy
Create OUs to restrict access
Chapter 2
Creating OUs to Delegate Administration
Ive mentioned that OUs can be used to create administrative areas in a domain. Using OUs, you
can delegate administrative tasks to subordinate administrators. For example, suppose the
engineering department wants to administer its own objects and resources in the Chicago
domain. You can accomplish this setup by creating the following OU:
engineering.chicago.company.com. After youve created the new OU and placed all the objects
and resources into it, you can grant explicit permissions to the administrators of the engineering
department so that they can control their own objects. Figure 2.12 illustrates how you can create
the Engineering OU in the Chicago domain.

Figure 2.12: You can create the engineering OU in the Chicago domain, then assign permissions to the
engineering department administrators to manage all the objects.

54
Chapter 2
Another useful feature that I mentioned earlier is that OUs can be nested. This feature enables
you to build a hierarchy in each domain. For example, suppose that the testing group in the
engineering department wants full administrative control over all its resources, such as users,
printers, and computers. To accommodate this request, you simply create a new OU directly
under the Engineering OU in the Chicago domain. The hierarchical structure now looks like the
following: testing.engineering.chicago.company.com. After youve created the new OU and
placed the resources, you can give full privileges to the testing groups administrator. If an OU is
nested, it inherits the properties of the parent OU by default. For example, if the Engineering OU
has certain security or GPOs set, theyre passed down to the Testing OU. The Testing OU is
considered nested under the Engineering OU.
Be careful to limit the number of OU layers you create. Creating too many layers can increase the
administrative overhead. Limiting the number of OU layers also increases user logon performance.
When a user logs on to AD, the security policies take effect. To find all these policies, the workstation
must search all layers of the OU structure. Having fewer OU layers allows the client to complete this
search more quickly.
Creating OUs to Reflect Your Companys Organization
If you dont create OUs in your domain, all users, printers, servers, computers, and other
resources are displayed in a single list. This type of layout makes it difficult to search for
resources. This problem increases as the number of objects in the domain grows.
One of the many benefits of creating OUs in a domain is the organization of this flat layout. OUs
allow you to create an organization that reflects your companys divisions, departments, and
groups. In fact, you can use your companys organizational chart or a similar document to help
you. Figure 2.13 illustrates how you can create OUs based on an organizational chart.

Figure 2.13: OUs have been created in a domain based on an organizational chart.

55
Chapter 2

56
Creating OUs for Group Policy
Group Policy enables you to define desktop configurations for users and computers. Desktop
configurations have settings that govern and control the users experience at their workstations.
GPOs can also be associated with an OU. This association allows all users and computers in the
OU and any nested OUs to receive the settings defined in Group Policy. These settings configure
several items, including installed software, registry settings, and logon scriptsjust to name a
few.
The ability to set Group Policy on OUs allows you to control a large set of users and computers
from a central point. If you have a special need for certain users and computers, you can create
an OU and establish Group Policy. For example, if the Accounting Department needs specific
settings on its desktops, you can create an OU=Accounting and establish the specific policy.
Group Policy will then apply to every user and computer in the new OU.
As I mentioned earlier, GPOs can be associated with OUs as well as the domain and site objects
in AD. Because GPOs can be associated with each of these objects, you can create
implementations using GPOs to generate various combinations. If you arent careful, these
combinations can become very complicated and cause you headaches.
Creating OUs to Restrict Access
The quickest and easiest way to restrict total access to network resources is to create a new OU
and place the network resources into it. You can then restrict access to the OU, thereby removing
access to the network resources. In addition, the objects representing the network resources are
no longer visible.
Users who dont have the right to read an object can normally still see it in AD. This visibility
may be a problem if you have highly secure network resources that you dont want anyone else
to see. You can restrict and hide the resources by creating a new OU in the domain and limiting
access to only the few who need it.
Designing the Sites for the Forest
Sites are locations on the physical network that contain AD servers. A site is stored in AD as an
object and is defined as one or more well-connected TCP/IP subnets. By well-connected, I
mean that the network connectivity among the subnets is highly reliable and supports a data-
transfer rate of at least 10 megabits per second (Mbps)in other words, your typical LAN at
your typical office location.
Designing sites and site links in AD takes advantage of the physical network layout. The basic
assumption is that servers and workstations with the same subnet address are connected to the
same network segment and have LAN speeds. Defining a site as a set of subnets allows
administrators to easily configure AD access and replication topology to take advantage of the
physical network. Sites also help you locate network servers so that theyre physically close to
the users who depend on them.
For an explanation of site links, see Creating Sites and Site Links Based on Network Topology later
in this chapter.
Chapter 2
Its your role as an administrator to design the site objects and site links for your tree or forest
that assure the best network performance. Its also your job to determine what speed assures this
performance and reduces server downtime as a result of network outages. Establish site objects
and site links based on network and subnet speed. Although many subnets can belong to a single
site, a single subnet cant span multiple physical sites. To help you establish a design for the sites
in your forest, you need to consider the following guidelines:
Create sites and site links based on network topology
Use sites to determine the placement of domain controllers
Use sites to determine the placement of GC servers
Creating Sites and Site Links Based on Network Topology
When you create sites and site links for your tree or forest, use the physical layout of your
network, or topology. Before you can properly create sites and site links, you need a solid
understanding of what they are.
About Sites
Sites are groups of computers (or subnets) that share high-speed bandwidth connections on one
or more TCP/IP subnets. Subnets are groups of local segments on the network that are physically
located in the same place. Multiple site objects create a site topology. Figure 2.14 portrays a site
with TCP/IP subnets that exist between the servers and workstations. A LANas opposed to a
WAN, MAN, or other lower-speed connectionalways connects a site.

Figure 2.14: A site is one or more TCP/IP subnets or LAN networks that exist between the servers and
workstations.

57
Chapter 2

58
One domain can span more than one site, and one site can contain multiple domains. However, for
design purposes, its important to remember that sites define how replication occurs among domain
controllers and which domain controller a users workstation contacts for initial authentication.
Normally, the workstation first tries to contact domain controllers in its site.
About Site Links
Site links are objects that represent the WAN links on your network. They also represent any
low-bandwidth connections between two locations. Site links connect two or more sites. They
help you determine the replication schedule and latency, and they help you determine where to
place network servers. The rule is to create a site link when a connection is slower than a LAN-
speed connection. Defining site links allows administrators to configure AD and replication to
take advantage of the network.
The site link object has four settings:
CostHelps the replication process determine the path of the communication among
domain controllers; the cost of every site link along a potential replication path is added
up, and the least expensive path is utilized
Replication scheduleDetermines what time of day the replication process can execute
Replication intervalHelps the replication process determine how often to poll the
domain controllers on the other side of the link
TransportHelps the replication process determine which transport protocol to use
during communications
Site and site link objects are stored in a special container called the configuration container. The
configuration container is stored and replicated to every AD domain controller, providing each
server with complete details of the physical network topology. A change to any of the
information in the site or site link objects causes replication to every domain controller in the
forest.
Chapter 2
Creating the Site Topology
Sites and site links create the site topology, as Figure 2.15 illustrates. The site topology helps the
replication process determine the path, cost, and protocol among domain controllers.

Figure 2.15: The site topology is created from the site objects and the site links. The site topology helps the
replication process determine the path, cost, and protocol among domain controllers.
When you create the site topology, its useful to have a complete set of physical LAN and WAN
maps. If your company has campus networks at one or more locations, youll need to have the
physical maps of those locations. These maps should include all the physical connections, media
or frame types, protocols, and speed of connections.
When defining the sites, begin by creating a site for every LAN or set of LANs that are
connected by high-speed bandwidth connections. If there are multiple physical locations, create a
site for each location that has a LAN subnet. For each site that you create, keep track of the IP
subnets and addresses that comprise the site. Youll need this information when you add the site
information to AD.
Site names are registered in DNS by the domain locator, so they must be legal DNS names. You
must also use Internet standard charactersletters, numbers, and hyphens. (For more information,
see Using Internet Standard Characters earlier in this chapter.)
After youve created the sites, you need to connect them with site links to truly reflect the
physical connectivity of your network. To do so, you need to first assign each site link a name.
By default, site links are transitive, just like trust relationships in AD. Thus, if Site A is
connected to Site B, and Site B is connected to Site C, its assumed that Site A can communicate
with Site C. This transitive connectivity is called site link bridging, and by default, AD creates
bridges throughout all site links.

59
Chapter 2

60
The practical upshot of bridging is this: Imagine that you have three sites, A, B, and C. A is
connected to B, and B is connected to C. When you create the two site links to represent these
connections, theyll be named something like AtoB and BtoC (for example). AD will
automatically bridge these connections, creating a transitive link from A to C. Domain
controllers in site A will therefore replicate with domain controllers in site B and in site C. The
idea behind site bridging is to reduce replication latency by allowing domain controllers at
various sites to replicate with one another directly. You can disable site bridging, forcing A to
replicate only with B, and preventing any changes made at site A from reaching site C until site
C replicates them from site B over its private site link. You can also manually create site link
bridges, if desired, to shortcut the site topology and reduce replication latency.
The process of generating this site replication topology is automatic, and its handled by a special
service called the Knowledge Consistency Checker (KCC). If you dont like the topology that the
KCC generates for you, you can create the topology manually.
The purpose of creating the site topology is to ensure rapid data communications among AD
servers. The site topology is used primarily when setting up replication of AD. However, the
placement of the domain controllers and partitions govern when and how replication takes place.
Using Sites to Determine the Placement of Domain Controllers
After youve properly created site and site link objects, you can use them to help you decide how
to properly distribute AD partitions across the network servers. Network servers are the domain
controllers that store AD domains and their copies. One domain controller holds only one copy
of an AD partition or domain. The server works to authenticate users and provide responses to
queries about the objects and attributes.
Your responsibility is to determine where to place the domain controllers on the network to best
suit the needs of the users. I recommend that the domain controllers be located on or near the
users subnet or site. When a workstation connects to the network, it typically receives a TCP/IP
address from DHCP. This TCP/IP address identifies the subnet or site to which the workstation is
attached. If the workstation has a statically assigned IP address, it will also have statically
configured subnet information.
In either case, when users log on to the network, their workstations can reach the closest domain
controller site by knowing the assigned address and subnet information. Because computers in
the same site are physically close to each other, communication among them is reliable and fast.
Workstations can easily determine the local site at logon because they already know what
TCP/IP subnet theyre on, and subnets translate directly to AD sites.
If no domain controller is available in the local site, user traffic will cross the WAN links and
sites to find other servers. To place the domain controller for best overall connectivity, select the
site where the largest numbers of users are located. All the users in that site will authenticate to
the local domain controller. This approach guarantees that the users will retrieve their object
information from the GC partition. The location of the server is important because users are
required to access a GC server when they log on.
Chapter 2

61
Using Sites to Determine the Placement of DNS Servers
Ive already mentioned that DNS and AD are inseparably connected. AD uses DNS to locate the
domain controllers. The DNS service enables users workstations to find the IP addresses of the
domain controllers. The DNS server is the authoritative source for the locator records of the
domains and domain controllers on the network. To find a particular domain controller, the
workstation queries DNS for the appropriate service (SRV) and address (A) resource records.
These records from DNS provide the names and IP addresses of the domain controller.
The availability of DNS directly affects the availability of AD and its servers. As mentioned,
users rely on DNS as a service. To guarantee DNS as a service, I recommend that you place or
have available at least one DNS server for every site on your network. This setup allows all users
to access the DNS service locally. You dont want users to have to query DNS servers that are
offsite to locate the domain controllers that are on the users own subnet.
The AD domain controllers query DNS to find each other during replication. A new domain controller
participates in replication by registering its locator records with DNS. Likewise, each domain controller
must be able to look up these records. Such is the case even if the domain controllers are on the
same subnet.
If you depend on an outside DNS service, you might need to adjust the number of DNS servers
and physical placement, if possible. Youll also need to verify that the outside DNS service
supports the required SRV resource record. If it doesnt, you may need to install and configure
your own implementation of Microsofts DNS to support AD.
If you dont want to depend on an existing DNS service or a DNS service that is offsite, you
might want to install the Microsoft DNS service that is integrated into AD. The Microsoft DNS
service stores the locator records for the domain and domain controllers in AD. You can then
have one or more domain controllers provide the DNS service. Again, I recommend that you
place at least one DNS server for each site object in your environment. Using the Microsoft DNS
service is an optional configuration, and storing the locator records in AD may have a negative
impact on replication traffic on large networks.
Summary
My first recommendation for troubleshooting AD is to make sure that its components are
designed and implemented correctly. In addition, the efficiency of AD depends on the design and
implementation of key structuresforests, trees, domains, and OUs. I also recommend that the
sites and site links be properly established to support the distribution and replication of the
system. In this chapter, we explored these topics as well as the placement of other supporting
servers, such as domain controllers, GC servers, and DNS servers. The design and
implementation of these structures is strictly your responsibility as network administrators.
Before you can effectively troubleshoot AD, make sure you feel confident about your design.
Chapter 3

62
Chapter 3: Monitoring and Tuning the Windows Server 2003
System and Network
A Windows Server 2003 (WS2K3) network is a system of devices that work together toward the
common goal of providing communication among users, servers, and applications. The most
important of these devices are WS2K3 domain controllers. This guide is primarily interested in
the components and software that are required for WS2K3 Active Directory (AD) services. This
chapter focuses on how you can monitor WS2K3 domain controllers and their subsystems to
help you reduce downtime and improve AD performance.
Monitoring WS2K3 Domain Controllers
Domain controllers are the single most important type of device on an AD-based WS2K3
network. These devices share the responsibility of storing the directory information, and they
interact with each other to replicate the directory information and keep it up to date. In addition,
domain controllers are responsible for authenticating user logons and servicing other requests for
access to directory and network resources. Domain controllers are also the gatekeepers to
changes in the domain, as all domain configuration, security, and operational changes must be
made through a domain controller. Because domain controllers are crucial to the performance
and operation of the directory, its critical that you continually monitor these servers. A poorly
performing or misbehaving domain controller can easily cause network downtime and loss of
directory functionality. For example, when the directory slows significantly or is unavailable,
users cant log on, there is no Address Book for Exchange, and users may not be able to print or
access Web-based applications.
When you consider how youll monitor your domain controllers, first remember that no one
domain controller contains all of the directory information. In any well-built WS2K3 network,
each domain partition in the directory typically has two or more domain controllers hosting the
domain to provide fault tolerance for directory services. With this kind of redundancy in place,
you might initially be fooled into thinking that monitoring each domain controller for
performance and downtime isnt all that important.
However, each domain controller plays a role in supporting your users. For example, if two
domain controllers in the same directory partition are placed in separated sites or subnets, users
in each site will use the domain controller nearest them. However, if one of the domain
controllers goes down, users in that location must traverse the wide area network (WAN) to log
on and access the directory. This traversal is usually undesirable, especially if there are too many
users and/or if the WAN link is slow.
Chapter 3

63
Another example of why you need to monitor domain controllers is that some domain controllers
on a WS2K3 network (no matter how many domain controllers it may have) are unique. For
example, some domain controllers perform special duties called Flexible Single-Master
Operation (FSMO) roles. Although the replication of AD is multimaster, the FSMO roles held
by these domain controllers are single-master (much like a Windows NT 4.0 primary domain
controllerPDC). Thus, these domain controllers dont have additional copies or replicas to
provide fault tolerance if the domain controller hosting a particular role is down.
These FSMO domain controllers perform special roles for AD, such as managing the domain,
managing the schema, and supporting down-level clients. If any of these critical domain
controllers go down, the directory loses functionality and can no longer update or extend the
schema, or add or remove a domain from the directory.
Failing to monitor domain controllers can adversely affect a networks performance and
availability. For example, if an entire department is unable to access the domain controller or
directory, users lose time, and the company loses money. To help you ensure that your domain
controllers are available, you can, and should, monitor and analyze Windows in the five
following areas:
Overall system
Memory and cache
Processor and thread
Disk
Network
Ill discuss each of these areas, and the reason for their importance, in the following sections. Ill
discuss monitoring AD itself in Chapter 4.
Another critical monitoring area is auditing. Although auditing is usually considered a security-
related task, auditing can play a crucial role in operational issues as well. For example, if a
domain controller that has been performing acceptably suddenly slows, what is the first question
that youll ask yourself: What changed? Monitoring elements such as the memory, disk, and
network will tell you that something changed, but not what; only proper auditing can provide the
clue as to what changed.
Unfortunately, Windows auditing leaves a lot to be desired from a reporting and investigative
point of view. For example, each domain controller maintains its own audit logs; in a large
company with many domain controllers, poring through each of them to find out what changed
in the domain can be a time-consuming task. So much so, in fact, that few administrators ever
turn to auditing as a troubleshooting tool. Later in this chapter, well explore examples of how
auditing can be an effective troubleshooting tool and how you can make auditing more efficient
and useable.
Chapter 3

64
Monitoring the Overall System
Monitoring a Windows domain controller means watching the operation of both the servers
operating system (OS) and its hardware subsystems. When you monitor domain controllers,
begin by establishing a performance and reliability baseline for eachthat is, a nominal and
acceptable level of operation under real-world conditions on your network. Establishing a
baseline allows you to track the operation of the domain controller over time. If a potential
problem or bottleneck occurs, you can recognize it immediately it because you can compare that
behavior with the baseline established for that domain controller.
Another way to think about a baseline is in terms of health, a concept increasingly recognized by
products such as Microsoft Operations Manager (MOM). Consider this: Performance datasuch
as the fact that the CPU is running at 60 percent capacityis interesting, but it has no context. Is
60 percent good? Is it bad? For a server that normally averages 40 percent, 60 percent represents
a significant increase; for a server normally averaging 80 percent, 60 percent is a marked
improvement. For a server that normally shows 60 percent, it is the status quo. Its these
comparisons to whats normalthe baselinewhich adds context to performance data and
creates a health indicator: good, bad, really bad, or whatever you like to call it. Without a
baseline for comparison, performance data is just interesting numbers.
Monitoring domain controllers means watching for problems or bottlenecks in the OS and its
subsystems. A simple example of a bottleneck occurs when a domain controllers processor is
running at 100 percent usage because one application has tied up the CPU. Almost every
Windows administrator has seen this occur at some point.
Windows provides several utilities that can assist you in monitoring your domain controllers and
their subsystems. These tools provide features that will help you search for bottlenecks and other
problems:
Task ManagerGives you a quick view of which applications and processes are running
on the domain controllers. This utility allows you to view a summary of the overall CPU
and memory usage for each of these processes and threads.
Chapter 3

65

Performance consoleAllows you to view the current activity on the domain controller
and select the performance information that you want collected and logged. You can
customize WS2K3s performance-counter features and architecture to allow applications
to add their own metrics in the form of objects and counters, which you can then monitor
using the Performance console. By default, the Performance console has two
applications, System Monitor and Performance Logs and Alerts.
System Monitor enables you to monitor nearly every aspect of a domain controllers
performance and establish a baseline for the performance of your domain controllers.
Using System Monitor, you can see the performance counters graphically logged and set
alerts against them. The alerts will appear in Event Viewer.
The Performance Logs and Alerts application enables you to collect information for those
times when you cant detect a problem in real time. This application allows you to collect
domain controller performance data for as long as you wantdays, weeks, or even
months.
Event ViewerAllows you to view the event logs that gather information about a
domain controller and its subsystems. There are three types of logs: the Application Log,
the System Log, and the Security Log. Although the event logs start automatically when
you start the domain controller, you must start Event Viewer manually.
When monitoring domain controllers using the Performance consoles logging feature, make sure you
dont actually create a problem by filling the computers disk with large log files. Be sure to only
include those statistics in the logging process that you absolutely need. Keep the sampling period to
the minimum required to evaluate domain controller performance and usage. To select an appropriate
interval for your computer, establish a baseline of performance and usage. Also, take into account the
amount of free disk space on your domain controller when you begin the logging process. Finally,
make sure that you have some application in place (such as the Performance console) that
continually monitors the domain controller to ensure that it has plenty of free disk space.
In addition to monitoring the local domain controller, you can use the Performance console to monitor
domain controllers remotely and store the log files on a shared network drive. Doing so enables you
to monitor all the domain controllers in a directory from one console or utility.
At the heart of the Performance console and Task Manager are the performance counters that are
built-in to the Windows OS. Ill introduce each of these monitoring utilities briefly in the
upcoming sections and demonstrate how they can help you monitor specific subsystems. Keep in
mind that this chapter isnt intended to be an in-depth study of all the capabilities of these
utilities. Instead, the intention is to provide a general introduction to them and show you how you
can use them to assist you in monitoring your domain controllers.
Chapter 3
Using Task Manager
The easiest and quickest way to view how each application or system process is using the CPU
and memory is by using Windows Task Manager. This utility allows you to see which processes
or threads are running on a Windows domain controller at any given moment; it also shows a
summary of overall CPU and memory usage. To launch Task Manager, either right-click the
taskbar (typically at the bottom of the screen) and choose Task Manager or press Ctrl+Alt+Del,
then click Task List from the menu. Figure 3.1 shows an example of Task Manager.

Figure 3.1: Windows Task Manager allows you to view and manage the applications and processes running
on a domain controller and manage their performance.
Task Manager supplies five pages of information: Applications, Processes, Performance,
Networking, and Users. Each of these pages will help you understand more about a domain
controllers processes and memory. Ill discuss some of these screens in greater detail later in
this chapter.

66
Chapter 3
Using the Performance Console
In WS2K3, one of the main utilities for monitoring a domain controller is the Performance
console. The Performance console allows you to view the current activity on the domain
controller and select the performance information that you want collected and logged.
In NT, the Performance console was known as Performance Monitor, and like most NT administration
utilities, it was a standalone utility rather than a Microsoft Management Console (MMC) snap-in.
The Performance console helps you accurately pinpoint many of the performance problems or
bottlenecks in your system. It monitors your WS2K3 domain controller by capturing the selected
performance counters that relate to the system hardware and software. The performance counters
are programmed by the developer of the related system. The hardware-related counters typically
monitor the number of times a device has been accessed. For example, the physical disk counters
indicate the number of physical disk reads or writes and how fast they were completed. Software
counters monitor activity related to application software running on the domain controller. To
launch the Performance console, choose Start, Programs, Administrative Tools, Performance.
The first application that starts in the Performance console is System Monitor. Using System
Monitor, you can view the current activity on the domain controller and select information to be
collected and logged for analysis. You can also measure the performance of your own domain
controller as well as that of other domain controllers on your network. Figure 3.2 shows System
Monitor.

Figure 3.2: The Performance console includes both System Monitor and Performance Logs and Alerts.

67
Chapter 3
When it starts, System Monitor isnt monitoring any counters or performance indicators for the
system. You determine which counters System Monitor tracks and displays. To add a counter,
click the addition sign (+) icon on the toolbar or right-click anywhere in the System Monitor
display area and choose Add Counters from the shortcut menu. Using either approach, the Add
Counters dialog box appears, which Figure 3.3 shows, in which you can choose the counters to
monitor.

Figure 3.3: In System Monitor, you can choose which counters you want to track and monitor on the display.
Once you choose the counter that you want to view, System Monitor tracks performance in real
time. When you first start using System Monitor, the number of counters that are available seems
overwhelming because there are counters for almost every aspect of the computer. However, in
the spirit of the age-old 80/20 rule, youll probably find that you tend to use about 20 percent of
the available counters 80 percent of the time (or more), using the other counters only when you
need specific monitoring or troubleshooting information.
If you dont understand the meaning of a particular Performance console counter, highlight it and click
Explain. The informational dialog box that appears provides a description of the selected counter
(and, in some cases, what the various values or ranges might indicate).
Later sections of this chapter discuss how you can use System Monitor to monitor memory, view
processes, and monitor network components on a domain controller as well as monitor the disk
subsystem.

68
Chapter 3

69
Event Viewer
As with its NT and Win2K predecessor, WS2K3 uses an event logging system to track the
activity of each computer and its subsystems. The events that are logged by the system are
predetermined and tracked by the OS. In addition, WS2K3 provides Event Viewer, which allows
you to view the events that have been logged.
Events Tracked in Event Logs
Windows domain controllers occasionally encounter serious error conditions and halt operation.
This situation is called a stop error (also informally known to some users as the blue screen of
deathBSOD). The error message is displayed on a solid blue background on a domain
controllers console. Several stop errors are worth monitoring because they affect the reliability
of a computer. Fortunately, stop errors are recorded in a domain controllers event logs when the
computer restarts. To view the stop errors in the event logs, you need to launch Event Viewer.
In addition to stop errors, if a Windows domain controller restarts, these events are recorded in
the System Log section of the event logs. The reasons for a restart could include OS crashes, OS
upgrades, and hardware maintenance.
Another type of event that a domain controller tracks in the event logs is application crashes.
Windows uses the Dr. Watson utility (Drwtsn32.exe) to record problems and failures in
applications running on the domain controller. Failures are recorded in the Application Log
section of the event logs. Again, you can use Event Viewer and the information in the event logs
to analyze problems with an application.
Types of Event Logs
When you use Event Viewer, the event logs are separated into three logs, as follows:
Application LogContains events logged by applications or programs such as Exchange
or IIS that are running on the computer. The developer of an application decides which
events to record.
System LogContains events logged by the subsystems and components of the domain
controller. For example, if a disk driver has problems or fails, it records the events in the
System Log. You can use this log to determine the general availability and uptime of the
domain controller.
Security LogRecords security events, such as when a user successfully logs on or
attempts to log on. This log also records events that relate to file access. For example, an
event is recorded when a file is created, opened, or deleted. By default, the Security Log
can only be seen by systems administrators.
Additional logs are often created on domain controllers, including a dedicated log for the DNS
Server service, if its installed. These logs provide information specific to particular services,
making it somewhat easier to track the information you need.
Chapter 3
Starting Event Viewer
The event logs start automatically when you start the domain controller; you must start Event
Viewer manually. To start or display Event Viewer, choose Start, Run, type
event vwr
then click OK, or choose Start, Programs, Administrative Tools, Event Viewer. Event Viewer
starts and displays the screen that Figure 3.4 shows.

Figure 3.4: The startup screen or display for Event Viewer.
Only a user with administrative privileges can view the Security Log. Regular users can only view the
Application Log and System Log.

70
Chapter 3

71
Types of Events Logged by Event Viewer
Event Viewer logs several types of events, each of which has a different severity to help you
analyze a problem:
ErrorSignifies that a severe problem has occurred. This event means that data or
functionality was lost. For example, if a service fails to load during startup or stops
abruptly, an error is logged.
WarningIs less significant than an error and indicates that a problem could occur in the
future. For example, a warning is logged if disk space becomes too low.
InformationDescribes important situations that need noting. This event is typically
used to notify when an operation is successfulfor example, a disk driver loaded
successfully and without errors.
Success auditLogs successful access to a secured system resource such as a file or
directory object. A success audit event is a successful security-access attempt. For
example, if a user attempts to log on to the system and is successful, a success audit event
is logged.
Failure auditIs the opposite of the success audit event. For example, if a user attempts
to log on to the system or access a secured resource and fails, a failure audit is logged.
Sorting and Filtering Events
Using Event Viewer, you can sort events on the screen so that you can easily review and analyze
the information. To sort events on the screen, choose View, Newest First (the default) or Oldest
First.
In addition to selecting the sort order for events, you can filter them. Filtering events allows you
to select and view only the events that you want to analyze. To set a filter for events in Event
Viewer, choose View, Filter Events. Figure 3.5 shows the dialog box that appears to help you
specify the filter characteristics.
Chapter 3

Figure 3.5: Events can be filtered in Event Viewer to restrict the list of events that are displayed.
Exporting Events
In addition to sorting and filtering events in Event Viewer, you can export events in a variety of
formats to use with applications such as Microsoft Excel. To export events, choose Action,
Export List. When the Save As dialog box appears (see Figure 3.6), you can type a file name
with the .xls extension or choose a file type such as Text (Comma Delimited) (*.csv).

72
Chapter 3

Figure 3.6: The events in Event Viewer can be exported for use with various applications.
A major shortcoming of the Windows event logs, which Ive already mentioned, is the fact that
each server maintains it own logs. If youre relying on system-generated events or auditing
events to help provide troubleshooting clues, you might find yourself running around to a dozen
domain controllers to determine whether any of them have anything of use in their logs.
Microsoft provides a basic solution in its Audit Collection Service (ACS), which is designed to
aggregate log data into a central Microsoft SQL Server database. However, ACS is only
designed to work with the Security Log, again focusing on the security uses of auditing and not
the operational and troubleshooting aspects.
Monitoring Memory and Cache
One of the most common performance problems with Windows domain controllers (and all
servers, for that matter) is excessive paging, which is caused by insufficient random access
memory (RAM). In this situation, one of the greatest performance gains you can achieve is
adding more physical RAM to a system. Therefore, I recommend that the first subsystem you
monitor be the domain controllers memory and cache. Problems caused by lack of memory can
often appear to be problems in other parts of the system. For instance, a lack of memory can
cause insufficient file system cache, which can lead to and be seen as a performance problem in
the disk subsystem.
Before I give you the details of monitoring your domain controllers memory, Ill first briefly
introduce the memory model for Windows. Memory in Windows provides a page-based virtual
memory management scheme (called Virtual Memory ManagerVMM) that allows
applications to address 4 gigabytes (GB) of memory. Memory in Windows is able to do exactly
that by implementing virtual addresses. Each application is able to reference a physical chunk of
memory, at a specific virtual address, throughout its lifetime. VMM takes care of whether the
memory should be moved to a new location or swapped to disk completely independently of the
application.

73
Chapter 3

74
Because everything in the system is realized using pages of physical memory, its easy to see
that pages of memory become scarce rather quickly. VMM uses the hard disk to store unneeded
pages of memory in one or more files called paging files. Paging files represent pages of data
that arent currently being used but may be needed spontaneously at any time. By swapping
pages to and from paging files, VMM is able to make pages of memory available to applications
on demand and provide much more virtual memory than the available physical memory.
One of the first monitoring or troubleshooting tasks youll carry out is to verify that your domain
controller has enough physical memory. Table 3.1 shows the minimum memory requirements for
a WS2K3 domain controller.
Installation Type Memory Requirement
Minimum installation 256MB
Server running a basic set of services 512MB
Server running an expanded set of services 1GB or more
Table 3.1: Minimum memory requirements for a WS2K3 domain controller.
Your physical memory requirements for actual production servers will typically be much higher
if you expect decent performance. Because your domain controllers will at least be running AD,
I recommend that you always start with at least 512 megabytes (MB) RAM. If you want to load
other applications that come with their own memory requirements, youll need to add memory to
support them.
If there isnt enough memory on your domain controller, it will start running slower as it pages
information to and from its hard drive. When physical memory becomes full and an application
needs access to information not currently in memory, VMM moves some pages from physical
memory to a storage area on the hard drive called a paging file.
As the domain controller pages information to and from the paging file, the application must
wait. The wait occurs because the hard drive is significantly slower than physical RAM. This
paging also slows other system activities such as CPU and disk operations. As I mentioned
earlier, problems caused by lack of memory often appear to be problems in other parts of the
system. To maximize the performance and availability of your domain controller servers, its
important for you to understand and try to reduce or eliminate wherever possible the
performance overhead associated with paging operations.
Fortunately, there are a couple of utilities that you can use to track memory usage. Two of the
most common are utilities Ive already introduced: Task Manager and the Performance console.
Chapter 3
Using Task Manager to View Memory on a Domain Controller
You can use Task Manager to view memory usage on a domain controller. To do so, click the
Performance tab. Figure 3.7 shows an example of the Performance page in Task Manager
running on WS2K3.

Figure 3.7: The Performance page of WS2K3s Task Manager allows you to view a domain controllers
memory usage.

75
Chapter 3

76
The Performance page in Task Manager contains eight informational panes. The first two are
CPU Usage and CPU Usage History. These two panes and the Totals pane all deal with usage on
the CPU, or processor. The remaining panes can be used to analyze the memory usage for the
domain controller and include the following:
PF UsageA bar graph that shows the amount of paging your domain controller is
currently using. This pane is one of the most useful because it can indicate when VMM is
paging memory too often and thrashing. Thrashing occurs when the OS spends more time
managing virtual memory than it does executing application code. If this situation arises,
you need to increase the amount of memory on the system to improve performance.
Page File Usage HistoryA line graph that tracks the size of virtual memory over time.
The history for this pane is only displayed in the line graph and not recorded anywhere.
You can use this information to help determine whether there is a problem with virtual
memory over a longer period of time.
Physical MemoryThis pane tells you the total amount of RAM in kilobytes (KB) that
has been installed on your domain controller. This pane also shows the amount of
memory that is available for processes and the amount of memory used for system cache.
The amount of available memory will never go to zero because the OS will swap data to
the hard drive as the memory fills up. The system cache is the amount of memory used
for file cache on the domain controller.
Commit ChargeThis pane shows three numbers, which all deal with virtual memory on
the domain controller: Total, Limit, and Peak. The numbers are shown in kilobytes. Total
shows the current amount of virtual memory in use. Limit is the maximum possible size
of virtual memory. (This is also referred to as the paging limit.) Peak is the highest
amount of memory that has been used since the domain controller was started.
Kernel MemoryShows you the total amount of paged and non-paged memory, in
kilobytes, used by the kernel of the OS. The kernel provides core OS services such as
memory management and task scheduling.
I mentioned that you can easily and quickly check the memory usage on your domain controller
by using Task Manager. Task Manager allows you to see the amount of virtual memory in use.
Using the Performance Console to Monitor Memory on a Domain Controller
In addition to using Task Manager, you can use the Performance console to determine whether
the current amount of memory on a domain controller is sufficient. The System Monitor
application in the Performance console allows you to graphically display memory counters over
time. I also recommend that you display the memory cache counters.
Chapter 3
Available Memory Counters
To determine whether there is a bottleneck in memory, you need to check three memory
counters:
Available Bytes (under the Memory object in System Monitor)
Available Kbytes (kilobytes or KB)
Available Mbytes (megabytes or MB)
You can use any of these three counters to understand your domain controllers memory
commitment. I recommend that you reserve at least 20 percent of available memory for peak use.
To view one or all of the available memory counters, either click the Plus (+) tool on the toolbar
or right-click anywhere in the display area and choose Add Counters from the shortcut menu.
Once the Add Counters dialog box appears, choose Performance Object, Memory, then choose
one of the available memory counters. Figure 3.8 shows the Available Bytes counter of the
memory Performance Object.

Figure 3.8: Using the Available Bytes memory counter to monitor or track how much memory is left for users
or applications.

77
Chapter 3

78
The Available Bytes counter shows the amount of physical memory available to processes
running on the domain controller. This counter displays the last observed value only; it isnt an
average. Its calculated by summing space on three memory lists:
FreeMemory that is ready or available for use
ZeroedPages of memory filled with zeros to prevent later processes from seeing data
used by a previous process
StandbyMemory removed from the working set of a process and en route to disk but
still available to be recalled
If Available Bytes is constantly decreasing over a period of time and no new applications are
loaded, it indicates that the amount of working memory is growing, or it could signal a memory
leak in one or more of the running applications. A memory leak is a situation in which
applications or processes consume memory but dont release it properly. To determine the
culprit, monitor each application or process individually to see whether the amount of memory it
uses constantly increases. Whichever application or process constantly increases memory
without decreasing it is probably the culprit.
Page-Fault Counters
When a process or thread requests data on a page in memory that is no longer there, a domain
controller issues a page fault. Here, the page has typically been moved out of memory to provide
memory for other processes. If the requested page is in another part of memory, the page fault is
a soft page fault. However, if the page has to be retrieved from disk, a hard page fault has
occurred. Most domain controllers can handle large numbers of soft page faults, but hard page
faults can cause significant delays.
Page-fault counters help you determine the impact of virtual memory and page faults on a
domain controller. These counters can be important performance indicators because they
measure how VMM handles memory:
Page Faults/secIndicates the number of page faults without making a distinction
between soft page faults and hard page faults
Page Reads/secIndicates the number of times the disk was read to resolve hard page
faults; this counter indicates the impact of hard page faults
Pages Input/secIndicates the number of pages read from disk to resolve hard page
faults; this counter also indicates the impact of hard page faults
Chapter 3
Figure 3.9 illustrates how you can use System Monitor to track page-fault counters.

Figure 3.9: The Page Faults/sec, Page Reads/sec, and Pages Input/sec counters determine the impact of
virtual memory and paging.
If the numbers recorded by these counters are low, your domain controller is responding quickly
to memory requests. However, if the numbers are high and remain consistently high, its time to
add more RAM to the domain controller.
Paging File Usage
Another important set of counters helps you determine the size of virtual memory. These
counters are related to paging file usage. Before I discuss how you can effectively use these
counters, its important that you better understand the paging file and its function. The paging
file is the space on a domain controller that enables the OS to swap out memory to the hard
drive. As the domain controller loads more applications than it can run in actual memory, it
pages some memory to the hard drive to create room for the new applications.
You can see how much the paging file is being used by watching two counters under the Paging
File object:
% UsageIndicates the current usage value that was last recorded
% Usage PeakIndicates the high watermark for the paging file

79
Chapter 3

80
If a domain controller was perfect, the OS would have enough memory for every application that
was loaded and would never page memory out. Both the % Usage counter and the % Usage Peak
counter would be at zero. The opposite is that the domain controller is paging memory as fast as
possible, and the usage counters are high. An example of a bad situation is one in which your
domain controller has 128MB of memory, the % Usage Peak counter is at 80 percent, and the %
Usage counter is above 70 percent. In this situation, its fairly certain that your domain controller
will be performing poorly.
By default, Windows automatically creates a paging file on the system drive during installation.
Windows bases the size of the paging file on the amount of physical memory present on the
domain controller (in most cases, its between 768MB and 1536MB). In addition to this paging
file, I recommend that you create a paging file on each logical drive in the domain controller. In
fact, I recommend that you stripe the paging file across multiple physical hard drives, if possible.
Striping the paging file improves performance of both the file and virtual memory because
simultaneous disk access can occur on multiple drives simultaneously.
The recommendation for using disk striping on the paging file works best with Small Computer
System Interface (SCSI) drives rather than those based on Integrated Device Electronics (IDE)
interfaces. The reason is that SCSI handles multiple device contention more efficiently than IDE and
tends to use less CPU power in the process. Also, I dont recommend that you spread the paging file
across multiple logical drive volumes (partitions) located on the same physical drive. Doing so wont
generally aid paging file performanceand it may actually hinder it.
To change or set the virtual memory setting on your domain controller, right-click My Computer,
then choose Properties from the shortcut menu. In the System Properties dialog box, click the
Advanced tab, then click Performance Options. Notice that the Performance Options dialog box
allows you to see the current setting for Virtual Memory. Next, click Change to display more
information and to change the paging file settings.
Changing the paging file size or location is unfortunately one of those rare setting changes in WS2K3
that requires you to restart the domain controller before the change takes effect. Thus, if you decide
to change any settings for the paging file, do so during a scheduled maintenance time when its safe
to take the domain controller down and doing so wont affect your users.
System Cache
In addition to tracking the amount of memory and virtual memory in the domain controller, you
need to keep an eye on the computers system cache settings. The system cache is an area in
memory dedicated to files and applications that have been accessed on the domain controller.
The system cache is also used to speed both file system and network input/output (I/O). For
example, when a user program requests a page of a file or application, the domain controller first
looks to see whether its in memory (system cache). The reason is that a page in cache responds
more quickly to user requests. If the requested information isnt in cache, the OS fulfills the user
request by reading the file page from disk.
Chapter 3

81
If the system cache isnt large enough, bottlenecks will occur on your domain controller. The
Cache object in System Monitor and its counters help you understand caching in Win2K. In
addition, several counters under the Memory object help you determine the amount of file cache.
Two of the counters that best illustrate how the file cache is responding to requests are:
Copy Read Hits %This counter is under the Cache object and tracks the percentage of
cache-copy read requests that are satisfied by the cache. The requests dont require a disk
read to give the application access to the page. A copy read is a file-read operation that is
satisfied by a memory copy from a page in the cache to the applications buffer.
Cache Faults/secThis counter is under the Memory object and tracks the number of
faults that occur when a page sought in the system cache isnt found. The page must be
retrieved from elsewhere in memory (a soft fault) or from the hard drive (a hard fault).
When youre considering using the Copy Read Hits % counter to assess file-cache performance, you
might also consider tracking the Copy Reads/sec counter, which measures the total number of Copy
Read operations per second. By assessing these numbers together, youll have a better sense of the
significance of the data provided by the Copy Reads Hits % counter. For example, if this counter were
to spike momentarily without a corresponding jump (or perhaps even a decrease) in the number for
overall Copy Reads/sec, the data might not mean much. Ideally, you can identify a cache bottleneck
when there is a steady decrease in the Copy Read Hits % counter with a relatively flat Copy
Reads/sec figure. A steady increase in both counters, or an increase in Copy Read Hits % and a
relatively flat Copy Reads/sec, indicates good file cache performance.
Thus, the Copy Read Hits % counter records the percentage of successful file-system cache hits,
and the Cache Faults/sec counter tracks the number of file-system cache misses. Figure 3.10
shows these counters in System Monitor. Remember that one of the counters is a percentage and
the other is a raw number, so they wont exactly mirror each other.
Chapter 3

Figure 3:10: The Copy Read Hits % and the Cache Faults/sec counters show how the domain controllers
cache is responding.
Generally speaking, I recommend that a domain controller have at least an 80 percent cache hit
rate over time. If these two counters show that your domain controller has a low percentage of
cache hits and a high number of cache faults (misses), you may want to increase the total amount
of RAM. Increasing the RAM allows the domain controller to allocate more memory for system
cache and should increase the cache hit rate.

82
Chapter 3

83
Monitoring Processors and Threads
Many people mistakenly believe that the focus of monitoring a domain controller is primarily the
domain controllers physical processor(s), or CPUs. However, the truth is that the processor
doesnt do anything unless there are processes and threads to run. In Windows, a process is made
up of one or more threads that run on the CPU. A bottleneck at the processor typically means
that either one or more processes are consuming most of the processor time or there are too many
threads contending for the CPU.
A process is an executable program that follows a sequence of steps. Each process requires a
cycle from the domain controllers processor as it runs. A thread is the component of a process
that is being executed at any time. Thus, a process must contain at least one thread before it can
perform an operation. A single process executing more than one thread is referred to as being
multithreaded. Windows is a multithreaded OS that is capable of running multiple processor
threads simultaneouslyeven, when theyre present, across multiple CPUs.
When an application is developed, the developer determines the number of threads each process
will use. In a single-threaded process, only one thread is executed at one time. In a multithreaded
process, more than one thread can be executed concurrently. Being multithreaded allows a
process to accomplish many tasks at the same time and avoid unnecessary delay caused by
thread wait time. To change threads, the OS uses a process called context switching, which
interrupts one thread, saves its information, then loads and runs another thread.
In addition to the multithreaded and multitasking approach to handling processes and threads,
Windows allows priorities to be assigned to each process and thread. The kernel of the Windows
OS controls access to the processor using priority levels.
Using Process Viewer to Monitor Processes and Threads
Every domain controller comes with the Process Viewer utility (Pviewer.exe). This utility is part
of the Win2K Support Tools, which is located in the Support folder on the Windows CD-ROM.
Process Viewer is a useful tool for looking at the various processes and associated threads
currently running on your domain controller. To launch Process Viewer on your computer,
choose Start, Programs, Accessories, Command Prompt, then type pviewer. Figure 3.11 shows
an example of Process Viewer.
Chapter 3

Figure 3.11: The Process Viewer utility allows you to view the processes and threads running on your
domain controller.
Using this utility, you can view the name of each process, the amount of time each process has
been running, the memory allocated to each process, and the priority of each process. You can
also view each thread that makes up a selected process. For each thread, you can see how long it
has been running, its priority, context switches, and starting memory address.
In addition to the information you see on the main screen, you can display the memory details for
a process. Figure 3.12 illustrates the Memory Details dialog box that is shown when you select a
process and then click Memory Detail.

84
Chapter 3

Figure 3.12: Memory details for each process are displayed by clicking Memory Detail in Process Viewers
main window.
When using Process Viewer, you can stop or kill a process that is running on a domain controller by
selecting it and clicking Kill Process. However, be sure you understand the function and impact of
killing a process before doing sothe process might be vital to your domain controllers functionality.
Worse yet, by killing a process, you can irrecoverably lose or corrupt the data.
Using Task Manager to View Processes on a Domain Controller
Earlier, this chapter described a method of using Task Manager as the quickest and easiest
method of monitoring the performance of the CPU. You can also use Task Manager to see which
processes or threads are running on the Windows domain controller and to view a summary of
overall processor or CPU usage. To launch Task Manager, either right-click the taskbar and
choose Task Manager or press Ctrl+Alt+Del, then select Task List from the menu. Then click the
Processes tab. A list is displayed of the processes currently running on the domain controller.
Figure 3.13 shows an example of the processes running on Windows and displayed in Task
Manager.

85
Chapter 3

Figure 3.13: Windows Task Manager allows you to view and manage processes that are currently running on
the system.
This view provides a list of the processes that are runningtheir names, their process identifiers
(PIDs), the percentage of CPU processing theyre consuming, the amount of CPU time theyre
using, and the amount of memory theyre using. Notice the System Idle Process, which always
seems to be toward the top of the process list. This process is a special process that runs when the
domain controller isnt doing anything else. You can use the System Idle Process to determine
how the CPU is loaded because its the exact opposite of the CPU Usage value on the
Performance tab. For example, if the CPU Usage value is 5, the System Idle Process value will
be 95. A high value for the System Idle Process means that the domain controller isnt heavily
loaded, at least at the moment you checked.

86
Chapter 3
Working with the List of Processes
You can sort this list of processes according to one of the column labels mentioned earlier. For
example, if you want to view the processes in order of the amount of memory used, simply click
that columns label. The display or list will change accordingly.
Task Manager also allows you to customize the columns, thereby receiving additional
information about the processes and being able to assess as many as 23 parameters. To customize
the columns, on the Processes page, choose View, Select Columns. As Figure 3.14 shows, notice
that many additional columns of information can be displayed. These additional columns will
help you monitor and tune each process more completely. For more information about each of
the additional columns, refer to the Help menu in Task Manager.

Figure 3.14: The Select Columns dialog box in Task Manager allows you to monitor additional important
statistics about the processes that are running on your domain controller.
In addition, you can see which of these processes belong to an application. To do so, click the
Applications tab, right-click one of the applications on the Applications page, then click Go To
Process. Doing so will take you to the associated applications process on the Process tab. This
feature helps you associate applications with their processes.
Highlighting a process in Task Manager, then clicking End Process, stops that process from running.
This feature is useful because it allows you to stop processes that dont provide any other means of
being stopped. However, use this method only as a last resort because the process stops
immediately and doesnt have a chance to clean up its resources. Using this method to stop
processes may leave domain controller resources unusable until you restart. It may also cause data
to be lost or corrupted.

87
Chapter 3
Viewing Information About Processes
If you view the list of processes from either Process Viewer or Task Manager and dont know
what a process is, you can use the Computer Management utility to view the processes and their
associated file paths or locations. Computer Management also lets you view the version, size,
and date of the application or module for each process.
To view the Computer Management utility, choose Start, Programs, Administrative Tools,
Computer Management. Once the utility has loaded, select System Tools, System Information,
Software Environment, Running Tasks. Figure 3.15 displays processes and their associated
information in the Computer Management utility.

Figure 3.15: The Computer Management utility allows you to view the processes that are running on your
domain controller as well as the path and file name information associated with each process.
Using the Performance Console to View Processes on a Domain Controller
You can use the System Monitor application in the Performance console to view the values of
the performance counters for the processor, processes, and threads. This utility allows you to
graphically display these counters over time. In the next few sections, Ill discuss some of the
counters and how you can use them.

88
Chapter 3
% Processor Time Counter
The first counter that you should check when monitoring the domain controller is % Processor
Time. This counter gauges the activity of the computers CPU. It shows the percentage of time
that all processors in the domain controller are busy executing code other than the System Idle
Process. Acceptable processor activity ranges between 1 percent and 85 percent, although the
actual amount depends on the type of applications loaded on your domain controller.
The % Processor Time counter is a primary indicator of processor activity. This counter is
calculated by measuring the time that the processor spends executing the idle process, then
subtracting that value from 100 percent. It can be viewed as the percentage of useful work that
the processor executes. To view the % Processor Time counter, you use System Monitor. Figure
3.16 shows the % Processor Time counter in System Monitor.

Figure 3.16: The % Processor Time counter give you the ability to view the amount of time that the processor
is doing real work.
If the % Processor Time counter is consistently high, there may be a bottleneck on the CPU. I
recommend that this counter consistently stay below 85 percent. If it pushes above that value,
you need to find the process that is using a high percentage of the processor. If there is no
obvious CPU hog, consider adding another processor to the domain controller or reducing that
domain controllers workload. Reducing the workload might involve stopping services, moving
databases, removing directory services, and so on.

89
Chapter 3
Interrupts/sec Counter
The Interrupts/sec counter measures the rate of service requests from the domain controllers I/O
devices. This counter is the average number of hardware interrupts that the processor is receiving
and servicing each second. If this value increases without an associated increase in system
response, there could be hardware problems on one of the I/O devices. For example, a network
interface card (NIC) installed in the domain controller could go bad and cause an excessive
amount of hardware interrupts. To fix the problem, you need to replace the offending network
cards driver or the physical card.
The Interrupts/sec counter doesnt include deferred procedure calls; theyre counted separately.
Instead, this counter tracks the activity of hardware devices that generate interrupts, such as the
system clock, mouse, keyboard, disk drivers, NICs, and other peripheral devices. (For example,
the system clock interrupts the CPU every 10 millisecondsms.) When an interrupt occurs, it
suspends the normal thread execution until the CPU has serviced the interrupt.
During normal operation of the domain controller, there will be hundreds or thousands of
interrupts per second. System Monitor displays the counter as a percentage of the real number.
Thus, if the domain controller has 560 interrupts in one second, the value is shown as 5.6 on the
graph. Figure 3.17 displays the Interrupts/sec counter using System Monitor.

Figure 3.17: The Interrupts/sec counter allows you to view the impact the hardware I/O devices have on the
performance of the domain controller.

90
Chapter 3

91
In System Monitor, you can make changes to the graphic display. To do so, right-click anywhere on
the graph, then choose Properties from the shortcut menu. The System Monitor Properties dialog box
appears, containing several tabs to change the display and effect the graph and data. For example, if
you want to change the graphs scale, click the Graph tab and change the Vertical Scale parameters.
To confirm the change, click Apply, then OK.
Unfortunately, its difficult to suggest a definite threshold for this counter because this number
depends on the particular processor type in use and the exact role and use of the domain
controller. I therefore recommend that you establish your own baseline for this counter and use it
as a comparison over time. Doing so will help you know when a hardware problem occurs.
Processor Queue Length Counter
The Processor Queue Length counter under the System object displays the number of processes
or threads waiting to be executed in the run queue that is shared among all processors on the
server. This counter displays the last observed value only; its not an average. If there are too
many threads waiting for the CPU and the CPU cannot keep up, the system is processor-bound
and starts to slow. Figure 3.18 illustrates how System Monitor shows Processor Queue Length.

Figure 3.18: The Processor Queue Length counter indicates how congested the processor is.
Chapter 3

92
I recommend that your domain controller not have a sustained Processor Queue Length of
greater than two threads. If the number of threads goes above two, performance slows, as does
responsiveness to the users. The domain controller shown in the figure could be in trouble,
especially if this type of activity is sustained. There are several ways to alleviate the domain
controller slow. You can replace the CPU with a faster processor, add more processors, and
reduce the workload. In some situations, the Processor Queue Length counter will increase if the
system is paging heavily; adding memory or RAM could be the solution in this case. To
determine whether you need more RAM, monitor the paging counters.
Monitoring the Disk
Because the hard drives in the domain controller have moving parts, theyre always the slowest
subsystem in the computer. In fact, the hard drive subsystem will typically be more than 100,000
times slower than the memory subsystem. As a result, the architects of Windows designed the
file-system caching service. Its sole responsibility is to move data off the hard drives and into the
faster memory subsystem. This process minimizes the performance penalty of retrieving data
from the domain controller.
By nature, a hard drive is massive and cheap. The disk subsystem can contain hundreds of
gigabytes that store millions or billions of files. In turn, memory is relatively small and
expensive. Therefore, the architects of Windows designed the virtual memory system to store
pieces of memory on the hard drive, thereby allowing more room for users and applications.
However, as discussed earlier, you pay a performance price for paging.
Using the Performance Console to Monitor the Disk Subsystem
Because system performance depends so heavily on the disk subsystem, its important that you
understand how to monitor it. To properly monitor the disk subsystem, you need to monitor disk
usage and response time, which includes the number of actual reads and writes plus the speed
with which the disk accomplishes each request. The primary utility you use to monitor these
attributes is System Monitor in the Performance console. Using System Monitor, you can view
key counters that apply to physical device usage and the logical volumes on the drives.
% Disk Time and % Idle Time Counters
The % Disk Time counter under the PhysicalDisk object allows you to view how busy the
domain controllers hard drive is. This counter is a percentage of elapsed time that the hard drive
is busy servicing read and write requests. The % Idle Time counter under the PhysicalDisk object
reports the percentage of time the hard drive is sitting idle.
Using these counters, you can monitor the physical activity of the hard drives in each computer.
Figure 3.19 illustrates the % Disk Time and % Idle Time counters in System Monitor.
Chapter 3

Figure 3.19: The % Disk Time counter allows you to view how busy a physical disk drive is, and the % Idle
Time counter tracks the percentage of time a drive is idle.
Figure 3.19 shows that, as you might expect, % Disk Time and % Idle Time basically mirror
each other. I recommend that if the value for % Disk Time is consistently above 70 percent, you
consider reorganizing the domain controller to reduce the load. However, if the domain
controller is a database server, the threshold can go as high as 90 percent. The threshold value
depends on the type of server that has been implemented and what has caused the disk I/O. For
example, if VMM is paging heavily, it can drive up the % Disk Time counter. The simplest
solution is to add memory.
Disk Reads/sec and Disk Writes/sec Counters
In addition to the percentage of time the disk is busy, you can also see what the disk is doing.
You can monitor this activity by using two counters under the PhysicalDisk object in System
Monitor:
Disk Reads/sec counterTracks the rate of read operations on the disk
Disk Writes/sec counterTracks the rate of write operations on the disk
Normally, a domain controller will perform twice as many (if not more) read operations than
write operations; it can also service a read request at least twice as fast. The reason is that the
write request has to write the data, then verify that it was written. You can see the Disk
Reads/sec and Disk Writes/sec counters in System Monitor in Figure 3.20.

93
Chapter 3

Figure 3.20: The Disk Reads/sec and the Disk Writes/sec counters show how the domain controller is
handling disk requests.
Using these counters, watch for spikes in the number of disk reads when your domain controller
is busy. If you have the appropriate amount of memory on your domain controller, most read
requests will be serviced from the system cache instead of hitting the disk drive and causing disk
reads. You want at least an 80 percent cache hit rate, which means that only 20 percent of read
requests are forced to the disk. This recommendation is valid unless you have an application that
reads a lot of varying data at the same timefor example, a database server is by nature disk-
intensive and reads varying data. Obtaining a high number of cache hits with a database server
may not be possible.
Current Disk Queue Length Counter
The Current Disk Queue Length counter represents the number of requests outstanding on the
disk at any one time. The disk has a queue, or list, that can hold the read and write requests in
order until they can be serviced by the physical device. This counter shows the number of
requests in service at the time the sample is taken. Most disk devices installed on your domain
controller are single-spindle disk drives. However, disk devices with multiple spindles, such as
some Redundant Array of Independent Disks (RAID) disk systems, can have multiple reads and
writes active at one time. Thus, a multiple-spindle disk drive can handle twice the rate of
requests of a normal device. Figure 3.21 displays System Monitor tracking the length of the disk
queue.

94
Chapter 3

Figure 3.21: The Current Disk Queue Length counter represents the number of outstanding read and write
requests. Using this counter, you can monitor the performance of the queue for the disk drives.
If the disk drive is under a sustained load, this counter will likely be consistently high. In this
case, the read and write requests will experience delays proportional to the length of this queue
divided by the number of spindles on the disks. For decent performance, I recommend that the
value of the counter average less than 2.
Because gathering disk counters can cause a modest increase in disk-access time, WS2K3 doesnt
automatically activate all the disk counters when it starts up. By default, the physical disk counters are
on, and the logical disk counters are off. The physical disk counters monitor the disk driver and how it
relates to the physical device. The logical disk counters monitor the information for the partitions and
volumes that have been established on the physical disk drives.
To start the domain controller with the logical disk counters on, you use the DISKPERF utility. At the
command prompt, type DISKPERF YV. This sets the domain controller to gather counters for both
the logical disk devices and the physical devices the next time the system is started. For more
information about using the DISKPERF utility, type DISKPERF /? at the command prompt.
% Free Space Counter
An example of a logical disk counter is the % Free Space counter. This counter is the percentage
of the free space available on the logical disk or volume. Free space is calculated as a ratio of the
total useable space provided on the volume of the logical disk drive. This counter is obviously an
important one to monitor because it allows you to view the amount of disk space that is left for
user and application requests.

95
Chapter 3
This counter allows you to monitor the performance of the disk drives as they start to fill. This
task is important because as a disk drive starts to run out of space, each write request becomes
tougher to perform and slows overall disk performance. The reason is that as the drive fills, each
write takes longer to search for space. The longer it takes the disk to write the data, the less it
does, so performance slows. Thus, as the drive fills, it works harder to service requests; this is
often called thrashing. To minimize thrashing, leave at least 10 percent of the disk free.
Monitoring the Network
Each Windows domain controller depends on the network to move information to its users and to
other servers. However, if the network becomes too crowded and traffic exceeds capacity,
performance for all users and domain controllers will suffer. You need to monitor the network
components for each domain controller on your network to help eliminate bottlenecks.
Monitoring the network typically consists of observing usage on network components and
measuring the amount of traffic on the network.
Using Task Manager to Watch Network Traffic
In WS2K3, Task Manager also provides a quick and easy look at network utilization, as Figure
3.22 shows. This view allows you to quickly see current activity in a System Monitor-like view
without opening and configuring System Monitor.

Figure 3.22: Task Manager provides a quick look at network utilization for each installed network adapter.

96
Chapter 3

97
Using Network Monitor to Watch Network Traffic
Network Monitor (Netmon.exe) allows you to analyze in-depth, low-level network traffic and
enables you to detect and analyze problems on your local networks and WAN connections.
Network Monitor captures and displays the network packets that the WS2K3 domain controller
receives from users and other servers to provide real-time traffic monitoring and analysis. You
can also display the traffic in a post-capture mode to help you analyze it after the fact.
In real-time mode, Network Monitor allows you to monitor and test network traffic for a specific
set of conditions. If the conditions are detected, it displays the events and prompts you for the
appropriate action. In post-capture analysis, network traffic is saved in a proprietary capture file
and can be parsed by protocol to pick out specific network frame types. Network Monitor does
the following:
Captures network data in real-time or delayed mode
Provides filtering capabilities when capturing network packets
Uses parsers for detailed post-capture analysis
Using the Performance Console to Monitor Network Components on a Domain
Controller
You can use System Monitor in the Performance console to monitor the domain controllers
network performance. Specific performance counters allow you to watch the computers network
throughput and network interfaces.
Domain Controller Network Throughput
The easiest way to measure domain controller throughput and the bandwidth of each network
component is to determine the rate at which the computer sends and receives network data.
Several performance counters under the Server object in System Monitor can help you measure
the data transmitted through your domain controllers network components. These counters
represent all the network traffic sent to and received from the domain controller and all the NICs
installed on it:
Bytes Total/secThis counter shows the number of bytes the domain controller has sent
and received from the network each second. This value provides an overall indication of
how busy the domain controller is, servicing network requests. It can help you determine
whether any network components are creating bottlenecks for network traffic.
Bytes Transmitted/secThis counter shows the number of bytes that the domain
controller has sent on the network. It indicates the network traffic that has been sent.
Bytes Received/secThis counter shows the number of bytes that the domain controller
has received from the network. It indicates the network traffic that has been received.
Chapter 3

98
The advantage of the last two counters is that they break out the values for traffic sent and
received. I recommend that once youve monitored these counters, you compare the results with
your domain controllers total network throughput. To do so, establish a baseline of data rates
and averages. Establishing a baseline allows you to know what to expect from the domain
controller. If a potential problem or bottleneck in network throughput occurs, you can recognize
it immediately because you can compare it against the baseline youve established.
You can also make some estimates as to where a bottleneck exists if you know the network and
bus speeds of the domain controller. If the data rate through the card is approaching the network
limit, segmenting and adding a card may help. If the aggregate data rate is approaching the bus
speed, it may be time to split the load for the domain controller and add another one or go to
clustering.
Network Interface Throughput
If you want to break down the amount of traffic to each individual network adapter or interface
card, youll want to use the Network Interface object in System Monitor. The counters that
display the amount of traffic processed by each NIC are Bytes Total/sec, Bytes Sent/sec, and
Bytes Received/sec. The counters in the previous section have similar names, but they display
the amount of traffic for the entire domain controller, regardless of the actual number of interface
cards installed. Using the counters assigned to each network adapter allows you to drill down and
see how each performs individually:
Bytes Total/secThis counter shows the number of bytes the NIC has sent and received
from the network each second. This value measures the rate at which bytes are both sent
and received on the NIC, including all frame and media types. This value also provides
an overall indication of how busy the network adapter is.
Bytes Sent/secThis counter shows the rate at which bytes are sent on the network
interface. This value breaks down the amount of traffic being sent.
Bytes Received/secThis counter shows the rate at which bytes are received. This value
breaks down the amount of traffic being received.
Figure 3.23 illustrates how you can use the Bytes Total/sec, Bytes Sent/sec, and Bytes
Received/sec counters in System Monitor to monitor the domain controllers network adapter.
Chapter 3

Figure 3.23: The Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec counters allow you to monitor the
domain controllers network adapter.
All That MonitoringSo Little Information
All of these great toolsTask Manager, System Monitor, Network Monitor, and so fortharent
going to provide you with everything you need to troubleshoot AD. Certainly, these tools
provide valuable data, but as Ive already said, data is just numbers. What these tools dont do a
good job of providing is information. Simply put, information is data that has been put into some
kind of useful context, translated into terms you can understand, and presented in a meaningful
way. Another problem with these tools is that theyre completely separatetheres no one place
you can go to for all of this data, and because AD is such a complex, highly integrated system,
youll find yourself jumping between tools trying to correlate everything youre looking at.
MOM offers one solution for this problem. MOM does two important things: It aggregates all of
this data into one place so that you can see it on one screen. It also does some health monitoring;
it knows what Microsoft thinks constitutes a healthy server, and it matches your servers
performance data to those known health thresholds. Doing so places context on the performance
data, making it into information. Rather than looking at a screen telling you that you have four
hard page faults per second, youre looking at a screen that tells you that your server is
overworked and needs more memory installed. Information, then, is much more useful and
actionable than mere data.

99
Chapter 3

100
Other companies have taken a somewhat different approach. For example, NetPro offers
DirectoryTroubleshooter. Although this tool starts by aggregating an entire domain of
performance data into one place and goes one step further by placing some basic health
information on it, DirectoryTroubleshooter also looks beyond real-time performance statistics
and goes into configuration items that you might not otherwise be exposed to. For example,
DirectoryTroubleshooter can let you know if certain domain configuration parameters are set
outside ranges typically used for best performance. The tool can also run a number of best
practices reports to highlight areas of your domain controllers that might be performing
acceptably but that could be reconfigured to run better or provide more server capacity.
DirectoryAnalyzer performs a related set of services, helping to filter through the general mass
of performance data and event log entries and create specific alerts that highlight what you need
to focus on to prevent and repair AD problems.
Other tools, such as Winternals Insight for Active Directory, come at troubleshooting from the
other direction. Insight provides a way to look at low-level AD activity, almost serving as a
network monitor for whats going on inside of AD. Using Insight, you can see each and every
operation that AD performs in real-time. When troubleshooting complex problems such as
replication, for example, this ability is invaluable.
Make no mistake: You need to be looking at performance information, especially when
something goes wrong with AD. However, looking at performance information, rather than data,
is crucial. Third-party tools can often provide a level of aggregation and intelligence on top of
Windows built-in, data-driven tools to help you spot problems more quickly and solve them
more efficiently.
Auditing as a Troubleshooting Tool
Earlier, this chapter mentioned that auditing needs to gain more recognition for its value in
troubleshooting, above and beyond its value as a security tool. Being able to answer the
questions What changed? and Who changed it? are perhaps the most important first steps in
any troubleshooting exercise. Rather than spend hours staring at System Monitor graphs trying to
figure out what the problem is, you can use auditing to instantly tell that a fellow administrator
added 50 new site link bridges in ADtelling you right away why your domain controllers were
slowing.
Planning for Auditing
Auditing is an intensive activity. Windows auditing can be configured to a fairly granular level,
allowing you to, for example, configure auditing only for failed logons, successful domain
configuration attempts, and so forth. However, for troubleshooting purposes, you never know
what might cause a problem, so you pretty much need to turn on auditing full-blast on every
domain controller. Doing so is going to create quite a load on those machines; most sources will
recommend that you scale back and only capture those events that are vital to your operations. If
youre planning to use Windows built-in auditing architecture, consider sizing your domain
controllers with the assumption that full-blast auditing will be in use. If this consideration means
buying more domain controllers or specifying bigger servers, so be it; the security implications
of not auditing are severe, and troubleshooting and operational issues are even more important.
With auditing, you can solve problems quickly and efficiently; without it, youre basically
stumbling in the dark.
Chapter 3

101
Windows built-in auditing functionality logs events to the Windows event logs (specifically, the
Security Log, because security is what auditing is designed to address). Thus, all of the earlier-
mentioned caveats about the event logs hold true, particularly the inability to easily pull all of those
events into one place.
Other Auditing Techniques
Windows built-in auditing has, as Ive mentioned, two problems: First, its resource-intensive,
meaning youre less likely to use it. Second, the information is too scattered, meaning youll
have to connect to too many event logs in order to find the information you want. Filtering and
searching through those logs can be a nightmare. Products such as Insight for Active Directory
provide a different sort of real-time auditing by tapping into ADs own event processing queue,
grabbing activity as it occurs. This method is more resource-friendly, but Insight doesnt provide
long-term logging and analysis capabilities; its designed for real-time viewing.
Microsofts ACS aggregates log data (security log data, at least) and provides filtering and
searching capability, but it still relies on the Windows event log architecture. Thus, each domain
controller will have to be in full-on auditing mode at all times to be sure youre capturing
everything.
NetPro ChangeAuditor for Active Directory basically combines the Insight and ACS approaches.
The tool doesnt rely on the event log architecture, and instead taps into ADs own programming
interfaces to retrieve auditing information. This setup makes it a more resource-friendly solution.
It also includes long-term logging capabilities as well as built-in, intelligent reports, which can,
for example, quickly filter through the mass of event log entries youve acquired and display all
those relating to administrative group administration. ChangeAuditor also captures before and
after information for many events as well as whodunit information. This information can
allow you to quickly see whats changed in AD, who changed it, what it was changed from, and
what it was changed toeverything you need to quickly spot the source of a problem and correct
it rather than spending hours or days working on the symptoms.
The whole concept of change auditinglooking at whats changed in a networks configuration to
detect and prevent problemsis becoming more and more important to many companies. For more
information about change auditing and configuration management, check out The Definitive Guide to
Enterprise Network Configuration Management (Realtimepublishers.com) available from a link at
http://www.realtimepublishers.com.
Other tools exist to help answer the Who changed what? question. One is TripWire, a
configuration management tool that handles some basic AD configuration information. TripWire
is an excellent tool for determining who changes what on a single server; its not as capable
when it comes to the highly distributed AD. However, because many domain controller issues
result not from AD-specific changes but rather from per-server changes (someone removing a
memory module, for example), tools such as TripWire can be a valuable troubleshooting tool. It
can even alert you when key configuration elements change, helping you spot problems before
they actually occur. Similar tools, such as Configuresoft Enterprise Configuration Manager
(ECM), can also help you better manage the configuration on single servers and can even enforce
a desired configuration state on those machines, helping to ensure that problems dont occur due
to misconfigurations.
Chapter 3

102
Summary
As a network administrator, a critical part of your job is making sure that each and every domain
controller hosting AD is functioning properly. To accomplish this task, you need to properly
monitor each of these Windows domain controllers, which, in turn, means watching over the
critical OS components and hardware subsystems.
To help you monitor a domain controller and its subsystems, Windows provides several utilities,
and this chapter discussed the most important ones: Task Manager, the Performance console, and
Event Viewer. Using these utilities and third-party tools, you can watch server resources and
subsystems in real time while they work to support the requests by users, applications, and other
servers.
Chapter 4

103
Chapter 4: Monitoring and Auditing Active Directory
Troubleshooting Active Directory (AD) and AD-based networks requires that you become
familiar with AD constructs and monitoring tools and techniques. Monitoring AD allows you to
determine whether problems are occurring in any part of the directory. However, its sometimes
difficult to accurately determine the cause of a problem because AD is distributed across domain
controllers and interacts with several external services and protocols, such as:
Domain Name System (DNS) for name resolution
Lightweight Directory Access Protocol (LDAP) for directory lookups
Transmission Control Protocol/Internet Protocol (TCP/IP) for transport
AD also has a complex infrastructure that contains many components. To ensure the health of the
directory as a system, you must monitor all of these components. You also need to understand
ADs internal processes, such as replication.
As I described in the previous chapter, auditing changes to AD can also be a useful
troubleshooting tool, as auditing event messages can help you more quickly determine what has
recently changed in your AD configuration. Problems are most often the result of a change of
some kind; thus, knowing what changed can point you toward a solution.
This chapter will describe which infrastructure components you need to continually monitor to
ensure AD availability as well as some of the built-in and third-party utilities that are available to
help you do so. Its always a good idea to have a sound understanding of ones tools before using
them, so Ill start by introducing the tools in an effective monitoring tool set.
Using the Monitoring and Auditing Tools
You can use several tools to monitor the individual areas of AD and AD as a service or system.
These tools include built-in Windows utilities and support tools and resource kit utilities as well
as those available from third-party independent software vendors (ISVs). This chapter will give
you an overview of all of these utilities and describe how they can help you monitor the
directory. Rather than provide an exhaustive list of all the utilities built-in to Windows and
available on the market, this chapter will focus on the most useful of the built-in and third-party
tools.
Third-Party Tools
Its a shame that Windows doesnt come with every tool you could possibly need to troubleshoot
AD. However, Windows lacking offerings in this area offer third-party software vendors a rich
field to work with, and several vendors have created products designed to make troubleshooting
easier and more effective.
Chapter 4
DirectoryAnalyzer
DirectoryAnalyzer from NetPro was one of the first AD monitoring tools on the market, and it
performs real-time monitoring and alerting on all aspects of the AD infrastructure. Instead of
monitoring individual domain controllers, it monitors the directory as a whole. It does so by
monitoring all domain controllers and directory processes at once as a background process. If a
problem occurs at any level in the directory, DirectoryAnalyzer alerts, or notifies, users. If the
problem is critical, the tools integrated knowledge base contains descriptions and
troubleshooting methods that will help you solve it.
DirectoryAnalyzer monitors the individual structures and components of ADreplication,
domains, sites, Global Catalogs (GCs), operations master roles, and DNS (inasmuch as it relates
to AD). Each of these components is vital to the operation of AD. DirectoryAnalyzer can
monitor and alert based on specific conditions and problems in each of the individual structures.
The alerts are then recorded at the DirectoryAnalyzer client or console for viewing.
Alerts have two levels of severitywarning and critical. Warning alerts indicate that a
predetermined threshold has been met in one of the directory structures. Warning alerts help you
identify when and where problems may occur. Critical alerts indicate that a predetermined error
condition has been met. Critical alerts are problems that need your immediate attention; if you
ignore them, AD could lose functionality or the directory altogether.
By clicking Current Alerts under View Status in the left pane, you can display all of the alerts
with their associated type, time, and description. Figure 4.1 shows the Current Alerts screen in
DirectoryAnalyzer. The alerts have been recorded for the AD domain controllers, directory
structures, and directory processes.

Figure 4.1: DirectoryAnalyzer allows you to monitor the entire directory for problems.

104
Chapter 4
You can also send alerts to enterprise management systems using Simple Network Management
Protocol (SNMP). Doing so allows you to integrate DirectoryAnalyzer alerts with management
consoles such as Hewlett-Packards HP OpenView and Tivoli. Alerts can also be recorded in the
event logs of the Windows system and viewed using the Event Viewer utility.
DirectoryAnalyzer logs all alert activity to a history database. You can export the database and
analyze alert activity over time using a variety of formats, such as Microsoft Excel, Hypertext
Markup Language (HTML), Dynamic HTML (DHTML), and Rich Text Format (RTF). You can
also identify trends in the data, finding cycles or periods of high and low alert activity.
ChangeAuditor for Active Directory
Answering the questions who, what, when, and where, ChangeAuditor from NetPro starts out by
capturing ADs own internal traffic into a log. Rather than interpreting that log and displaying it,
however, ChangeAuditor analyzes that information and builds a detailed log file of every change
that occurs within AD. You cant view the AD traffic real-time; instead, you can run a series of
pre-created reports (or you can create your own reports) that display changes to various aspects
of AD. For example, you can run a report that displays changes made to built-in groups, quickly
showing you any membership changes to, say, the Domain Admins group. Figure 4.2 shows
ChangeAuditor in action, and as you can see, most of the time the tool is able to show you not
only what has changed but also what the original value was, who made the change, when the
change was made, and so forth.

Figure 4.2: ChangeAuditor displays recent changes to AD.
ChangeAuditor needs to be installed on each domain controller for maximum effectiveness, but
events are collected into a central database for reporting and analysis.

105
Chapter 4

106
Auditing for Troubleshooting
The previous chapter made a case for auditing as a troubleshooting tool. ChangeAuditor is quite definitely
an auditing tool: several of its bundled reports, for example, focus on considerations such as HIPAA
compliance, security issues, and so forth. This type of tool represents an important new way of thinking
about both auditing and troubleshooting.
For example, corporate auditing often relies too heavily on snapshot audits. In other words, an auditor
reviews the environment, as it looks today, for compliance with a set of corporate standards. The auditor
doesnt usually care what the environment looked like yesterday, or what it will look like tomorrow; theyre
only interested in what it looks like right now. Thats shortsighted, because any administrator who knows
the audit is coming can whip their environment into shape in time, then set things back to more
comfortable settings after the auditor is gone. By capturing and storing changes in a database, however,
ChangeAuditor allows auditors to look back in time. Auditors can see what changes were made to critical
groups, security settings, and so forth, and effectively audit the environment as it was
Of course, for troubleshooting purposes, knowing what changes occurred and when they occurred is
invaluable. By quickly reviewing all changes in the past 24 hours (or however long you need), you can
quickly spot a change that is related to a current problem. By seeing both the before and after values
of that change (which ChangeAuditor is able to display in many circumstances), you can quickly undo a
change and return your environment to working order.
DirectoryTroubleshooter
NetPros DirectoryTroubleshooter is a kind of super-performance monitor with built-in
intelligence. It monitors literally hundreds of AD-related configuration settings, performance
values, and other aspects of AD, and reports to you on potential problem areas (see Figure 4.3).
This functionality allows you to quickly focus your troubleshooting efforts on areas with a
known problem rather than shooting blind and spending hours analyzing areas of AD that arent
having a problem.
Chapter 4

Figure 4.3: DirectoryTroubleshooter displays a great deal of AD configuration information in one window.
DirectoryTroubleshooter can also help fix problems. It includes a set of jobs, which can perform
tasks such as configure recovery options on a server, start AD defragmentation, troubleshoot the
File Replication System (FRS), and so forth. These jobs can be targeted to run on multiple
servers, helping automate troubleshooting and repair.
Insight for Active Directory
Insight for Active Directory from Winternals Software is a sort of low-level event viewer for
AD. Essentially, Insight captures ADs LDAP communications for an entire domain, displaying
that information in a log, which you can analyze. As Figure 4.4 shows, Insight displays the log in
a color-coded format, helping you visually spot related information. A built-in translator of sorts
helps translate the somewhat-cryptic messages generated by AD into English-readable text.

107
Chapter 4

Figure 4.4: Insight for Active Directory displays real-time diagnostic information.
Pop-up tool tips display further explanations for messages, making ADs otherwise difficult
LDAP traffic easier to translate. Using Insight, you can see exactly what AD is doing at any
given moment, and often spot problems in operations such as replication by interpreting ADs
own internal traffic.
AppManager Suite
The AppManager Suite from NetIQ Corporation is a suite of management products that manages
and monitors the performance and availability of Windows. One of these management products
allows you to monitor the performance of AD. For example, AppManager verifies that
replication is occurring and is up-to-date for the directory by monitoring the highest Update
Sequence Number (USN) value for each domain controller. In addition, inbound and outbound
replication statistics are tracked, as are failed synchronization requests for the directory.
The USN is discussed in more detail later in this chapter.

108
Chapter 4

109
AppManager also allows you to monitor the number of directory authentications per second and
the cache hit rate of name resolution. Using this tool, you can monitor and track errors and
events for trust relationships. You can also log errors and events to enterprise management
systems using SNMP. Thus, SNMP traps are generated and routed to a configured network
manager.
In addition, you can use or run a set of prepackaged management reports that allow you to
further analyze current errors and events. You can also set up this utility to send email and pager
alerts when an event is detected.
Microsoft Operations Manager
Although not strictly a third-party product, Microsoft Operations Manager (MOM) is an
additional purchase from Microsoft (it is not a built-in tool). MOM is designed to provide health
monitoring services for Microsoft server products, including Windows and AD. The idea behind
MOMmuch like AppManageris to collect performance data and compare it with known
thresholds, translating raw performance data into more useful health information. For example,
knowing that your domain controllers processor utilization is at 70 percent may be interesting
data, but its not useful. Is 70 percent good or bad? MOM is designed to quickly compare that
data to a range of values known to represent good and bad server health conditions, and creates a
graphical view of services and server components that are operating at levels that may represent
a problem. MOM also checks several configuration parameters to help spot problems.
Built-In Tools
In this section, Ill discuss System Monitor, Event Viewer, and REPADMIN. These tools are
included with Windows and provide basic monitoring for key aspects of the OS and AD.
System Monitor
For the domain controller in AD, one of the main monitoring utilities is System Monitor. This
utility allows you to watch the internal performance counters that relate to the directory on the
domain controller. The directory performance counters are software counters that the developers
of AD have programmed into the system.
Using System Monitor, you can monitor current directory activity for the domain controller.
Once youve installed AD on a server, several performance countersfor replication activity,
DNS, address book, LDAP, authentication, and the database itselfmeasure the performance of
the directory on that computer.
Chapter 3 discussed how to launch and use System Monitor, so there is no need to repeat that
information. Instead, Ill focus on how to use some of the more important performance counters
that are available for AD. Remember, System Monitor tracks all of its counters in real time. For
this reason, it is a good practice to establish a baseline of normal operation that you can compare
the real-time values against. When adding AD counters to System Monitor, if you dont
understand the meaning of any counter, highlight it, then click Explain. The Explain Text dialog
box appears and provides a description of the counter.
You can also graph the performance counters and set alerts against them. The alerts will appear
in the Event Viewer.
Chapter 4

110
Event Viewer
To view and analyze the events that have been generated by a Windows domain controller, you
can use the Event Viewer. This utility allows you to monitor the event logs generated by
Windows. By default, there are three event logs: the application log, the system log, and the
security log.
These three logs are described in detail in Chapter 3.
In addition, after you install AD, three more logs are created:
Directory service logContains the events that are generated by AD on the domain
controller. You can use this log to monitor activity or investigate any directory problems.
By default, the directory records all critical error events.
DNS server logContains the events generated by the DNS service installed on your
domain controller. For example, when the DNS service starts or stops, it writes a
corresponding event message to this log. More critical DNS events are also loggedfor
example, if the service starts but cannot locate initializing data, such as zones or other
startup information stored in the domain controllers registry or AD. The DNS log exists
only if the DNS service is running on the server. The DNS service typically runs on only
a few domain controllers in the forest.
FRS logContains events generated by file replication on the domain controller. FRS is
a replication engine used to replicate files among different computers simultaneously. AD
uses this service to replicate Group Policy files among domain controllers.
Depending on how you configure your AD installation, you may have one or all of these logs on
your domain controller. Figure 4.5 shows the Event Viewer startup screen on a domain controller
AD with DNS has been installed.
Chapter 4

Figure 4.5: The Event Viewer startup screen lists additional event logs that have been created for AD.
Replication Diagnostics
The Replication Diagnostics tool is simply referred to as REPADMIN. Its a command-line
utility that allows you to monitor and diagnose the replication process and topology in AD. It
also provides several switches that you can use to monitor specific areas of replication. For
example, you can force replication among domain controllers and view the status.
During normal replication, the Knowledge Consistency Checker (KCC) manages and builds the
replication topology for each naming context on the domain controller. The replication topology
is the set of domain controllers that share replication responsibility for the domain. REPADMIN
allows you to view the replication topology as seen by the domain controller. If needed, you can
use REPADMIN to manually create the replication topology, although doing so isnt usually
beneficial or necessary because the replication topology is generated automatically by the KCC.
You can also view the domain controllers replication partners, both inbound and outbound, and
some of the internal structures used during replication, such as the metadata and up-to-date
vectors.

111
Chapter 4
You can install the REPADMIN.EXE utility from the support tools folder on the Windows
installation CD-ROM. Running the SETUP program launches the Support Tools Setup wizard,
which installs this tool along with many other useful support tools to the Program Files\Support
Tools folder. Figure 4.6 shows the interface for REPADMIN (the Win2K version is shown; the
WS2K3 version works identically).

Figure 4.6: The REPADMIN utility allows you to view the replication process and topology.
The Replication Topology
Its useful to remember how AD builds its replication topology. AD starts by having each domain controller
replicate with two partner domain controllers so that the domain controllers form a giant ring, replicating
changes in both directions around the ring. However, in a large domain, this topology would result in
significant replication latency.
For example, with a domain containing just a dozen domain controllers, a single change made on one
domain controller would have to take six hops in order to replicate to every other domain controller. For
that reason, AD is designed to shortcut the ring to prevent replication from taking more than three hops to
reach any given domain controller. These shortcuts create a third replication partner for specific domain
controllers, allowing replication to travel more quickly throughout the domain. Thus, no domain controller
should ever have more than three replication partners, which helps to minimize replication overhead on
any one domain controller.

112
Chapter 4

113
Monitoring the AD Infrastructure
An important aspect of any AD deployment is monitoring the environment and infrastructure.
The infrastructure of AD is the set of processes and data structures that the directory service uses
to function properly. By constantly monitoring the infrastructure, you can detect issues that arise
in the environment and correct them before they affect your users. For example, users will be
affected if there is an intermittent failure of a bridgehead server or if a Flexible Single Master
Operation (FSMO, pronounced fizmo) role-holding server goes down.
The first task in troubleshooting AD is to constantly monitor critical areas of the directory
deployment. I recommend that you continuously monitor at least the following directory
structures and components:
Domain controllersServers that are critical to the proper operation of AD. If one
domain controller isnt functioning properly, the directory and some users will lose
performance and possibly functionality. If the domain controller that is having problems
has also been assigned additional vital roles (such as being a DNS or GC server), the
directory may become unavailable to all users. Thus, its critical to monitor and track the
performance of all domain controllers on the network at all times.
Domain partitionPartition that stores AD objects and attributes that represent users,
computers, printers, and applications. The domain partition is also used to accomplish a
number of management roles, which include administration and replication. You must
monitor the performance and availability of the domain partition so that the services it
supports are constantly available.
GC partitionSpecialized domain controllers whose availability is necessary for clients
to be able to log on to the network. Only a few domain controllers store a copy of the GC
partition, and they need to be monitored for the GC. The GC streamlines directory
searches because it contains all of the objects in the forest but only a few of their key
attributes.
Operations mastersFSMO role holders are single-master domain controllers that
perform special roles for AD. Its important that you monitor and track the performance
of each operations master so that the service it performs is maintained. If any operations
master stops functioning, its functionality is lost in the directory.
Replication process and topologyAre critical to the operation of AD. If changes have
been made to a directory object on one domain controller, the replication process needs to
propagate the changes to all of the other domain controllers that have replicas of that
object. If replication isnt functioning, different portions of the directory get out of sync.
This confuses users, and they lose access to directory resources.
For example, if an administrator has changed a Group Policy but the change hasnt been
synchronized to all copies, users using the older copies may access the wrong
information. In addition, once the synchronization among directory replicas is lost, its
very difficult and time-consuming to get back. Thus, its critical to constantly monitor the
replication process and topology for problems.
Chapter 4
Monitoring the Domain Controllers
Because AD can be distributed across many domain controllers, you need to constantly monitor
individual domain controllers. If one domain controller isnt functioning properly, the directory
and your users will lose performance and possibly functionality. If multiple domain controllers
arent functioning properly, the network can become unusable. For this reason, always check or
monitor that the domain controllers hardware and subsystems are operating correctly. After
youre confident that the hardware is performing well, you need to monitor the AD services
running on the domain controllers for errors and other problems.
For details about monitoring the hardware components of the domain controller, refer to Chapter 3.
Using DirectoryAnalyzer
Many third-party tools, such as those I discussed earlier, provide you with an easy way to
monitor all of the domain controllers in your forest from one management console. For example,
in DirectoryAnalyzer, click Browse Directory By Naming Context; the directory hierarchy is
displayed. If you expand the naming contexts, you see all of the associated domain controllers.
To see the alerts for just one domain controller, select a domain controller object, then click
Current Alerts. The alerts that are displayed have exceeded a warning or critical threshold and
show the severity, subject, associated type, time, and description. Figure 4.7 shows an example
of using DirectoryAnalyzer to view all alerts for each domain controller.

Figure 4.7: DirectoryAnalyzer allows you to monitor all the domain controllers in your forest for problems
and see the alerts that have been recorded for each domain controller.

114
Chapter 4

115
To see the alerts and other information for each domain controller, you can also use the Browse
Directory By Site option. It allows you to browse the directory layout according to sites and their
associated domain controllers. In addition, it permits you to view the status of each site and the site
links.
DirectoryAnalyzer is an extremely useful utility because it monitors all of the domain controllers
in the AD forest as a background process and allows you to periodically view the results. It also
monitors the most critical directory structures and processesfor example, the configuration and
activity for the domain partitions, GC partitions, FSMO roles, sites, DNS, the replication
process, and the replication topology.
In addition to viewing the alerts from the domain controllers, you can click any alert and see a
more detailed description of the problem. If you dont understand the alert, you can double-click
it; the Alert Details dialog box will appear and provide more description, as Figure 4.8 shows.

Figure 4.8: DirectoryAnalyzer provides more information about an alert in the Alert Details dialog box.
Once youve been notified of the alert and viewed more information about it in the Alert Details
dialog box, you can use the integrated knowledge base to help resolve the problem. The
knowledge base provides you with a detailed explanation of the problem, helps you identify
possible causes, then helps you remedy or repair the problem. To access the knowledge base,
click More Info in the Alert Details dialog box or choose Help, Contents in the console. Figure
4.9 shows an example of the information available in the knowledge base.
Chapter 4

Figure 4.9: DirectoryAnalyzers in-depth knowledge base helps you find solutions to problems in AD.
Domain controllers are the workhorses of AD. They manage and store the domain information
and accept special functions and roles. For example, a domain controller can store a domain
partition, store a GC partition, and be assigned as a FSMO role owner. Domain controllers, in
turn, allow the directory to manage user interaction and authentication and oversee replication to
the other domain controllers in the forest.
In addition to displaying alerts for each domain controller, DirectoryAnalyzer displays detailed
configurations. For example, when you choose Browse Directory By Naming Context, you see
several icons for each domain controller. An icon that includes a globe indicates that the domain
controller stores a GC partition. When an icon displays small triangles, it indicates that the
domain controller is also providing the DNS service. An icon that displays both a globe and
small triangles indicates that the domain controller has both a GC and a DNS.

116
Chapter 4
If you select a domain controller and then click the DC Information tab, you can view detailed
information about how the domain controller is operating and handling the directory load. Figure
4.10 shows the DC Information pane in DirectoryAnalyzer.

Figure 4.10: You can view detailed information about a domain controller using the DC Information pane in
DirectoryAnalyzer.
DirectoryAnalyzer provides a high-level summary of how each domain and its associated
domain controllers are functioning. Click Browse Directory By Naming Context to see a high-
level status of all the domain controllers in a domain. To view the status for a particular domain,
select it, then click the DC Summary tab. Figure 4.11 shows the DC Summary pane, which uses
green, yellow, and red icons to indicate the status of each domain controller in a domain.

117
Chapter 4

Figure 4.11: The DC Summary pane in DirectoryAnalyzer provides a high-level status of all domain
controllers in a domain.
You can also quickly view where the domain controller resides, whether it is a GC server, and
who manages the computer. If any of the domain controllers arent showing a green (clear) status
icon, there is a problem that you need to investigate and fix.
Using NT Directory Service Performance Counters
NT Directory Service (NTDS) performance counters are internal domain controller counters
used by multiple aspects of AD. Once AD has been installed on the domain controller, these
directory counters are added to the system. These counters allow you to monitor and track the
domain controllers replication activity, LDAP traffic, and authentication traffic. Table 4.1
describes the more useful NTDS performance counters and how to use them to track AD activity
on a domain controller.

118
Chapter 4

119

Counter Function Description
DRA Inbound Bytes
Total/sec
Tracks the total number of
bytes per second received on
the server during replication
with other domain controllers.
Indicates the total amount of inbound
replication traffic over time. If a small
number of bytes are being sent, either the
network or the server is slow. Other issues
that might limit the number of bytes being
sent include few changes being made to the
naming contexts hosted by the domain
controller, replication topology problems,
and connectivity failures. Of course, you
need to check this value against a baseline
of activity.
DRA Inbound Object
Updates Remaining in
Packets
Tracks the number of object
updates received in the AD
replication update packet but
not applied to the local domain
controller.
Indicates that the server is receiving
changes but is taking a long time to apply
them to the AD database. The value of this
counter should be as low as possible. A
high value indicates that the network is slow
during replication or the domain controller is
receiving updates faster than it can apply
them. Other issues that can affect speed of
update are high domain controller load,
insufficient hardware (memory, disk, or
CPU), the disk becoming full or fragmented,
other applications using too many
resources, and so on.
DRA Outbound Bytes
Total/sec
Tracks the number of bytes that
are sent from the server during
replication to other domain
controllers.
Indicates the total amount of outbound
replication traffic over time. If this value
remains low, it can indicate a slow server or
network or few updates on this domain
controller. In the latter case, it can mean
that clients are connecting to other domain
controllers because this one is slow or that
there are topology problems. For best
results, test the current value against an
established baseline value.
DRA Pending
Replication
Synchronizations
Tracks the number of pending
requests from replication
partners for this domain
controller to synchronize with
them. Synchronizations are
queued, ready for processing
by the domain controller.
Indicates the backlog of directory
synchronizations for the selected server.
This value should be as low as possible. A
high value could indicate a slow server or a
problem with the servers hardware.
DS Threads in Use Tracks the current number of
threads that are being used by
the directory service running on
the domain controller.
Indicates how the directory service on the
server is responding to client requests.
When a client requests information, AD
spawns a thread to handle the request. If
the number of threads remains constant,
Win2K clients may experience a slow
response from the domain controller.
Kerberos
Authentications/sec
Tracks the current number of
authentications per second for
Indicates how the domain controller is
responding to client requests for
authentications. If this counter doesnt show
activity over time, clients could be having a
problem contacting the domain controller.
Chapter 4

120
LDAP Bind Time Tracks the amount of time (in
milliseconds) required to
process the last LDAP bind
request from the client. A bind
is described as authenticating
the LDAP client. This counter
tracks only the last successful
bind for an LDAP client.
The value of this counter should be as low
as possible to indicate that the domain
controller was quick to authenticate the
LDAP client. If the value is high, the domain
controller was slow to authenticate LDAP. A
high value can indicate a server problem,
the domain controller is too busy,
insufficient hardware (memory or CPU), or
other applications using too many
resources.
LDAP Client Sessions Tracks the current number of
LDAP sessions on the selected
domain controller.
If your domain controller has LDAP clients
trying to connect, the value of this counter
should show activity over time. If the value
remains constant, the server or client may
have problems, the domain controller may
be too busy running other applications, or
there is insufficient hardware (memory or
CPU).
LDAP Searches/sec Tracks the number of LDAP
search operations that were
performed on the selected
domain controller per second.
LDAP clients connecting to the
server perform the LDAP
search operations.
Indicates how many LDAP search requests
the domain controller is servicing per
second. You typically view different search
rates depending on the domain controllers
hardware, the number of clients connected
to the domain controller, and what sorts of
things the clients are doing.
LDAP Successful
Binds/sec
Tracks the number of LDAP
binds per second that occur
successfully.
Indicates how the domain controller
responds to authentications from the clients.
This value allows you to view the number of
successful binds per second for LDAP
clients. Again, if this value remains constant
over time, there can be a network, client, or
server problem. For example, there is a bad
network component, the client is too busy,
or the server is too busy.
NTLM Authentications Tracks the total number of
Windows NT LAN Manager
(NTLM) authentications per
second serviced by the domain
controller.
Allows you to see whether there are
authentications from Windows 98 and NT
clients for this domain controller. If youre
supporting Windows 98 and NT and the
value remains constant over time, there is a
network problem. For example, the network
could have a bad or poorly configured
component, or the client could be too busy.
Table 4.1: A few of the NTDS performance counters that allow you to track how a domain controller is
responding to replication traffic, LDAP traffic, and authentication traffic.
Chapter 4
NTDS counters enable you to monitor the performance of AD for the selected domain controller.
You can view these counters under the NTDS object in System Monitor (see Figure 4.12). By
default, System Monitor is started when you choose Start, Administrative Tools, Performance
Console.

Figure 4.12: NTDS performance counters allow you to monitor and track load and performance of the AD
implementation on each domain controller.
Monitoring the Domain Partitions
Domain partitions in AD are often referred to as naming contexts, and they provide a security
and replication boundary. Each domain partition exists in the NTDS.DIT database on the domain
controllers that participate in the domain. The domain partition stores all the users, printers,
servers, computers, and application data. Because users depend on the domain to access other
network resources, its important that you constantly monitor the state of the domain partition.

121
Chapter 4
DirectoryAnalyzer allows you to monitor the alerts for each domain in AD and the associated
domain controllers. These alerts monitor the domain controllers, replicas, Group Policies, trust
relationships, DNS, and other activity for a domain. If you see any critical alerts, you need to
investigate and fix the problems.
To view the alerts for a domain, click Browse Directory By Naming Context. Select a domain,
then click the Current Alerts tab. The display shows the current alerts for that domain (see Figure
4.13).

Figure 4.13: DirectoryAnalyzer allows you to monitor each domain partition for problems.
In addition to displaying alerts for each domain, DirectoryAnalyzer allows you to view
configuration information. Using the Naming Context Information tab, you can view the current
number of alerts that are active for the following areas: Naming Context (or Domain), Replica,
DNS Server, and DC Server.
The Naming Context Information tab also displays the number of domain controllers for the
domain and whether the domain supports mixed mode. When a domain supports mixed mode, it
allows replication and communication with down-level domain controllers and clients to occur.
In addition, you can see which domain controllers in the domain are performing the FSMO roles
and perform a FSMO consistency check. And finally, you can view all the trust relationships that
exist for the domain. Figure 4.14 shows the Naming Context Information pane in
DirectoryAnalyzer.

122
Chapter 4

Figure 4.14: The Naming Context Information pane in DirectoryAnalyzer allows you to see detailed
information for a domain.
To further monitor the domain, DirectoryAnalyzer provides a high-level summary of each
domain controller. Click Browse Directory By Naming Context, then click the DC Summary tab.
(The DC Summary pane is shown in Figure 4.11 earlier in this chapter.)
Using Domain Database Performance Counters
In AD, the database for the domain has been implemented as an indexed sequential access
method (ISAM) record or table manager. This table manager is often referred to as the
Extensible Storage Engine (ESE) and is implemented by ESENT.DLL on the server. By default,
the associated database file is stored on the Windows server as
<drive>\WINNT\NTDS\NTDS.DIT.
If necessary, you can relocate the NTDS.DIT database on a domain controller using the NTDSUTIL
utility, which is pre-installed.
Using this database engine, AD provides a set of database performance counters that allow you
to monitor the domain in depth. These counters provide information about the performance of
the database cache, database files, and database tables, and they help you monitor and determine
the health of the database for the domain controller. By default, database performance counters
arent installed on the domain controllers.

123
Chapter 4

124
You can view and monitor database counters using the System Monitor utility. Table 4.2 gives
you a general description of the more useful database performance counters and how to use them
to track the activity of the low-level database for each domain.
Cache % Hits Tracks the percentage of
database page requests in
memory that were successful. A
cache hit is a request that is
serviced from memory without
causing a file-read operation.
Indicates how database requests are
performing. The value for this counter
should be at least 90 percent. If its
lower than 90 percent, the database
requests are slow for the domain
controller, and you should consider
adding physical memory to create a
larger cache.
Cache Page Faults/sec Tracks the number of requests
(per second) that cannot be
serviced because no pages are
available in cache. If there are no
pages, the database cache
manager allocates new pages for
the database cache.
Indicates how the database cache is
performing. I recommend that the
computer have enough memory to
always cache the entire database. Thus,
the value of this counter should be as
low as possible. If the value is high, you
need to add more physical memory to
File Operations Pending Tracks the number of pending
requests issued by the database
cache manager to the database
file. The value is the number of
read and write requests that are
waiting to be serviced by the OS.
Indicates how the OS handles the
read/write requests to the AD database.
I recommend that the value for this
counter be as low as possible. If the
value is high, you need to add more
memory or processing power to the
domain controller. This condition can
also occur if the disk subsystem is
bottlenecked.
File Operations/sec Tracks the number of requests
(per second) issued by the
database cache manager to the
database file. The value is the
read and write requests per
second that are serviced by the
OS.
Indicates how many file operations have
occurred for the AD database. I
recommend that this value be
appropriate for the purpose of the
domain controller. If you think that the
number of read and write operations is
too high, you need to add memory or
processing power to the computer.
However, adding memory for the file
system cache on the computer reduces
file operations.
Table Open Cache
Hits/sec
Tracks the number of database
tables opened per second. The
database tables are opened by
the cached schema information.
Indicates how the AD database is
performing. The value for this counter
should be as high as possible for good
performance. If the value is low, you
may need to add more memory.
Table 4.2: Some of the more useful database performance counters, which allow you to monitor the database
for the domain partition that stores all of the AD objects and attributes.
Chapter 4

125
Installing the Counters
By default, database performance counters arent installed on the domain controller. To install
them, you must use the dynamic-link library (DLL) file called ESENTPRF.DLL. The
instructions for installing the counters are as follows:
1. Copy the %System%\System32\ESENTPRF.DLL file to a different directory. For
example, you can create a directory named C:\Perfmon, then copy the file to it.
2. Run the REGEDT32.EXE or REGEDIT.EXE registry editor and create the following
registry subkeys if they dont already exist
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT and
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\
Performance
3. Under the Performance subkey that you added in Step 2, add and initialize the data of the
following registry values:
Open: REG_SZ: OpenPerformanceData
Collect: REG_SZ: CollectPerformanceData
Close: REG_SZ: ClosePerformanceData
Library: REG_SZ: C:\Performance\esentprf.dll
4. Change directory to the %SystemRoot%\System32 folder (for example,
C:\Winnt\System32).
5. Load the counter information into the registry by executing the following statement:
LODCTR.EXE ESENTPRF.INI
Once youve installed the database performance counters, you can use them to track and monitor
the database on the domain controller. As mentioned earlier, you can view and track each
counter using the System Monitor utility in the Performance Console.
Monitoring the Global Catalog
As previous chapters have discussed, special servers on Windows networks store a GC partition,
which is replicated in AD. The domain controllers that contain the GC partition are referred to as
GC servers. Because only the first domain controller installed in a forest is made a GC, you need
to determine and specify which subsequent domain controllers will act as GC servers. In
addition, you need to constantly monitor the GC partition to ensure that it remains healthy.
The GC has been designed to support two crucial functions in an AD forest: user logons and
forest-wide queries or searches. It does so by storing all of the objects in the forest and the key
attributes for each. It doesnt store all the attributes for each object; instead, it stores only the
attributes it needs to perform queries and support the logon process. One of these attributes is the
distinguished name of the object.
Chapter 4
Once users query and retrieve the distinguished name from the GC, they can issue a search on
their local domain controller, and LDAP will chase the referrals to the domain controller that
stores the real object information. In addition, universal group membership is stored in the GC.
Because universal groups can deny access to resources, a users membership in this group must
be discovered during logon to build the logon access token. The requests made to the GC are
automatic and not seen by the user.
You can use DirectoryAnalyzer to monitor the GC partition and how its performing. It monitors
and tracks the following conditions:
Domain Controller: Global Catalog Load Too HighIndicates that the domain controller
that stores the GC partition has too much traffic. This traffic is LDAP traffic coming from
workstations and servers.
Domain Controller: Global Catalog Response Too SlowIndicates that the domain
controller that stores the GC partition isnt responding in time to queries and other traffic.
Replica: GC Replication Latency Too HighIndicates that replication is taking too long
to synchronize the GC stored on the domain controller. If replication latency (the time it
takes to replicate changes to all GCs in the forest) is too high, an alert is generated.
Site: Too Few Global Catalogs in SiteIndicates that there arent enough GC servers in
the site.
Figure 4.15 shows how DirectoryAnalyzer monitors and tracks alerts for the GC.

Figure 4.15: DirectoryAnalyzer allows you to monitor the GC partition that exists on various domain
controllers throughout the forest.

126
Chapter 4

127
Monitoring Operations Masters
To prevent conflicting updates in WS2K3, AD provides a single-master server to update certain
operations. In a single-master model, only one server is allowed to provide updates for the forest
or domain. When a domain controller takes on the responsibility of the single-master operation,
its taking on a role. Thus, this method of updates is called single-master operation roles. When
only one domain controller can take on the role at one time, its referred to as a FSMO role.
There are currently five types of operations masters in AD. The directory automatically elects the
FSMO role servers during the creation of each AD forest and domain.
For more detail about these FSMO roles, see Chapter 1.
Two operations masters manage forest-wide operations, so they have forest-specific FSMO
roles:
Schema masterResponsible for schema extensions and modifications in the forest
Domain naming masterResponsible for adding and removing domains in the forest
Three operations masters manage domain operations, so they have domain-specific FSMO roles:
Infrastructure masterUpdates group-to-user references in a domain
RID masterAssigns unique security IDs in a domain
PDC emulatorProvides PDC support for down-level clients in a domain.
The three domain-specific FSMO roles exist in every domain. Thus, an AD forest with a total of 3
domains would have 11 FSMO roles in all: 9 domain-specific roles and 2 forest-wide roles.
Because there is only one of each of the forest-specific FSMO roles, its extremely important that
you constantly monitor and track the activity and health of the operations masters. If any of them
fail, the directory loses functionality until the computer is restarted or another appropriate
domain controller is assigned the role.
To monitor operations masters, you can use DirectoryAnalyzer. It monitors, checks the status of,
and alerts on several types of conditions and situations relating to operations masters, such as
which domain controllers are holding the FSMO roles. Click Browse Directory By Naming
Context, and click the Naming Context Information tab. Under Operations Master Status, you
see which domain controller is holding which FSMO role. Figure 4.16 shows the status of the
FSMO roles in the Naming Context Information pane.
Chapter 4

Figure 4.16: DirectoryAnalyzer displays which domain controllers are holding which FSMO roles for the
naming context.
You can also use the Naming Context Information pane (shown in Figure 4.13) to check the
consistency of the FSMO roles across all of the domain controllers on the network.
DirectoryAnalyzer monitors what each domain controller reports for the FSMO assignments. If
not all of the domain controllers report the same values for all of the operations masters, the
word No appears beside Operations Master Consistent.
To investigate the problem, click Details. The Operations Master Consistency dialog box
appears, indicating that operations master information is inconsistent. It displays the names of
the domain controllers and which domain controller holds each role. In Figure 4.17, the domain
controller COMP-DC-04 has inconsistent information about the true owner of the PDC emulator
role because it shows domain controller COMP-DC-01 as the owner when it should be COMP-
DC-03. Thus, the owner of the PDC operations master is inconsistent.

128
Chapter 4

Figure 4.17: DirectoryAnalyzer allows you to monitor and check consistency for each operations master.
In addition to showing the status and consistency checks, DirectoryAnalyzer monitors and
displays alerts for each operations master. The alerts that are monitored and tracked provide
information about the availability of the FSMO roles. To monitor the availability of the FSMO
role holders, you can click Current Alerts in the bar to the side of the main screen. To display the
alerts for a domain or each domain controller, click Browse Directory By Naming Context.
The alerts indicate that the domain controller that holds the operations master isnt responding.
This lack of response could mean that the domain controller and AD are down and not
responding. It could also mean that the domain controller no longer has network connectivity,
which could indicate DNS or Internet Protocol (IP) addressing problems. Finally, this alert could
simply mean that the domain controller or the directory that is installed is overloaded and
responding too slowly. Figure 4.18 shows how DirectoryAnalyzer monitors and tracks alerts for
each operations master.

129
Chapter 4

Figure 4.18: DirectoryAnalyzer monitors and tracks the availability of each FSMO role holder.
Monitoring Replication
AD is a distributed directory made up of one or more naming contexts, or partitions. Partitions
are used to distribute the directory data on the domain controllers across the network. The
process that keeps partition information up to date is called replication. Monitoring replication is
critical to the proper operation of the directory. Before I discuss how to monitor replication,
however, I need to describe what it is and how it works.
In AD, replication is a background process that propagates directory data among domain
controllers. For example, if an update is made to one domain controller, the replication process is
used to notify all of the other domain controllers that hold copies of that data. In addition, the
directory uses multimaster replication, which means that there is no single source (or master)
that holds all of the directory information. Through multimaster replication, changes to the
directory can occur at any domain controller; the domain controller then notifies the other
servers.
Because AD is partitioned, not every domain controller needs to communicate or replicate with
each other. Instead, the system uses a set of connections that determines which domain
controllers need to replicate to ensure that the appropriate domain controllers receive the updates.
This approach reduces network traffic and replication latency (the time to replicate a change to
all replicas). The set of connections used by the replication process is the replication topology.

130
Chapter 4

131
Using Directory Partition Replicas
A directory partition replica can be a full replica or a partial replica. A full replica contains all of
the objects and attributes of a partition and is read- and write-accessible. A partial replica
contains a subset of the objects and attributes and is read-only. Partial replicas are stored only on
a GC server. Each domain controller stores at least three full directory partitions, or naming
contexts, which include the schema partition, configuration partition, and domain partition.
Schema Partition
The schema partition contains the set of rules that defines the objects and attributes in AD. This
set of rules is used during creation and modification of the objects and attributes in the directory.
The schema also defines how the objects and attributes can be manipulated and used in the
directory.
The schema partition is global; thus, every domain controller in the forest has a copy, and these
copies need to be kept consistent. To provide this consistency, the replication process in the
directory passes updated schema information among the domain controllers to the copies of the
schema. For example, if an update is made to the schema on one domain controller, replication
propagates the information to the other domain controllers, or copies of the schema.
Configuration Partition
The configuration partition contains the objects that define the logical and physical structure of
the AD forest. These objects include sites, site links, trust relationships, and domains. Like the
schema partition, the configuration partition exists on every domain controller in the forest and
must be exactly the same on each.
Because the configuration partition exists on every domain controller, each computer has some
knowledge of the physical and logical configuration of the directory. This knowledge allows
each domain controller to efficiently support replication. In addition, if a change or update is
made to a domain controller and its configuration partition, replication is started, which
propagates the change to the other domain controllers in the forest.
Domain Partition
The domain partition contains the objects and attributes of the domain itself. This information
includes users, groups, printers, servers, organizational units (OUs), and other network resources.
The domain partition is copied, or replicated, to all of the domain controllers in the domain. If
one domain controller receives an update, it needs to be able to pass the update to other domain
controllers holding copies of the domain.
A read-only subset of the domain partition is replicated to GC servers in other domains so that
other users can access its resources. This setup allows the GC to know what other objects are
available in the forest.
Chapter 4

132
Using Directory Updates
AD updates are changes made to an object or attribute stored on a domain controller. When an
update occurs, the domain controller that receives it uses replication to notify other domain
controllers holding replicas of the same partition. The domain controller that receives the update
(called the originating domain controller) notifies its replication partners of the change first, then
the partners requesting the appropriate changes.
A write request from a directory client is called an originating write. When an update that
originates on one domain controller is replicated to another domain controller, the update is
called a replicated write. Using this approach, AD can distinguish update information during
replication.
AD replication doesnt use date or time stamps to determine which changes need to be
propagated among domain controllers; instead, it uses Update Sequence Numbers (USNs). A
USN is a 64-bit counter that is associated with each object. It increments each time a change is
initiated, then its associated with the change. To view the USN of an object, use the following
command at a command prompt:
REPADMI N / showmet a <obj ect DN>
In addition to maintaining USNs, AD maintains an up-to-dateness vector, which helps the
domain controllers involved in replication track updates. The up-to-dateness vector is a table
containing one entry per naming context, which are the high-watermark USNs for each
replication partner. During replication, the requesting domain controller sends the up-to-dateness
vector with its replication request so that the originating domain controller sends only those
updates that the requesting domain controller doesnt already have.
The up-to-dateness vector also helps with the problems of multiple replication paths among
domain controllers. AD allows multiple replication paths to exist so that domain controllers can
use more than one path to send and receive replication traffic. When multiple replication paths
exist, you might expect redundant traffic and endless looping during replication, but the directory
allows domain controllers to detect when replication data has already been replicated. This
method is called propagation dampening.
AD prevents these potential problems by using the up-to-dateness vector and the high-watermark
vector. The up-to-dateness vector contains server-USN pairs and represents the latest originating
update. The high-watermark vector holds the USNs for attributes that have been added or
modified in the directory and that are stored in the replication metadata for that attribute. Using
both vectors, propagation dampening can occur and unnecessary directory updates avoided.
Chapter 4

133
As Ive mentioned, the values in the up-to-dateness vector can determine which updates need to
be sent to the destination domain controller. For example, if the destination domain controller
already has an up-to-date value for an object or attribute, the source domain controller doesnt
have to send the update for it. To view the contents of the up-to-dateness vector for any domain
controller, type the following command at a command prompt:
REPADMI N / showvect or <NC name>
To help resolve conflicts during replication, AD attaches a unique stamp to each replicated value.
Each stamp is replicated along with its corresponding value. To ensure that all conflicts can be
resolved during replication, the stamp is compared with the current value on the destination
domain controller. If the stamp of the value that was replicated is larger than the stamp of the
current value, the current value (including the stamp) is replaced. If the stamp is smaller, the
current value is left alone.
Using the Replication Topology
As I mentioned earlier, the replication topology is the set of connections used by the domain
controllers in a forest to synchronize the directory partition replicas. The replication topology is
created automatically on the basis of information in AD by the Knowledge Consistency Checker
(KCC), a built-in process that runs on all domain controllers. By default, the KCC runs at 15-
minute intervals and designates the replication routes among domain controllers on the basis of
the most favorable connections available at that time.
The KCC automatically generates replication connections among domain controllers in the same
site. This local replication topology is called an intra-site topology. If you have multiple wide
area network (WAN) locations, you can configure site links among the sites, then the KCC can
automatically create the respective replication connection objects. The replication topology that
is created among remote locations is called an inter-site topology. The sets of domain controllers
that replicate directly with each other are called replication partners. Each time the KCC runs,
these replication partners are automatically added, removed, or modified.
Although you can disable the KCC and create connection objects by hand, I strongly recommend
that you use the KCC to automatically generate the replication topology. The reason is that the KCC
simplifies a complex task and has a flexible architecture, which reacts to changes you make and any
failures that occur.
However, if your organization has more than 100 sites, you may need to manually create the
replication topology; in environments that have more than 100 sites, the KCC doesnt scale well. In
extremely large organizations, the KCC will often spend too much time and processing power trying
to calculate the replication topology, with the result that the topology will never be properly generated
and replication wont work properly between sites.
Chapter 4

134
The KCC uses the following components to manage the replication topology:
ConnectionsThe KCC creates connection objects in AD that enable the domain
controllers to replicate with each other. A connection is defined as a one-way inbound
route from one domain controller to another. The KCC manages the connection objects
and reuses them where it can, deletes unused connections, and creates new connections if
none exist.
ServersEach domain controller in AD is represented by a server object. The server has
a child object called NTDS Setting. This setting stores the inbound connection objects for
the server from the source domain controller. Connection objects are created in two
waysautomatically by the KCC or manually by an administrator.
SitesThe KCC uses sites to define the replication topology. Sites define the sets of
domain controllers that are well connected in terms of speed and cost. When changes
occur, the domain controllers in a site replicate with each other to keep AD synchronized.
If the domain controllers are local (intra-site topology), replication starts as neededwith
no concern for speed or costwithin 5 minutes of an update occurring. If the two domain
controllers are separated by a low-speed network connection (inter-site topology),
replication is scheduled as needed. Inter-site replication occurs only on a fixed schedule,
regardless of when updates occur.
SubnetsSubnets assist the KCC to identify groups of computers and domain
controllers that are physically close or on the same network.
Site linksSite links must be established among sites so that replication among sites can
occur. Unless a site link is placed, the KCC cannot automatically create the connections
among sites, and replication cannot take place. Each site link contains the schedule that
determines when replication can occur among the sites that it connects.
Bridgehead serversThe KCC automatically designates a single server for each naming
context, called the bridgehead server, to communicate across site links. You can also
manually designate bridgehead servers when you establish each site link. Bridgehead
servers perform site-to-site replication; in turn, they replicate to the other domain
controllers in each site. Using this method, you can ensure that inter-site replication
occurs only among designated bridgehead servers. Thus, bridgehead servers are the only
servers that replicate across site links, and the rest of the domain controllers are updated
within the local sites.
Chapter 4

135
DirectoryAnalyzer allows you to monitor replication among domain controllers and report any
errors or problems. It allows you to track the following problems and issues:
Replication CycleThe time during which the requesting domain controller receives
updates from one of its replication neighbors. You can view the successful replication
cycle as well as any errors that occurred during that time.
Replication LatencyThe elapsed time between an object or attribute being updated
and the change being replicated to all the domain controllers that hold copies. If
replication latency is too high, DirectoryAnalyzer issues an alert.
Replication TopologyThe paths among domain controllers used for replication. If the
replication topology evaluates that the topology is transitively closed (meaning that it
doesnt matter on which domain controller an update occurs), the topology will provide
for that update to be replicated to all other domain controllers.
Replication FailuresOccur when a domain controller involved in replication doesnt
respond. Each time there are consecutive failures from the same domain controller, an
alert is issued. Many things can cause failuresfor example, a domain controller may be
too busy updating its own directory information from a bulk load.
Replication PartnersSets of domain controllers that replicate directly with each other.
DirectoryAnalyzer monitors domain controllers and pings them to make sure that each is
still alive and working. If a replication partner doesnt respond, an alert is issued.
Replication ConflictOccurs when two objects or attributes are created or modified at
exactly the same time on two domain controllers on the network. AD resolves this
conflict automatically, and DirectoryAnalyzer issues an alert so that youll know that one
of the updates was ignored by replication.
DirectoryAnalyzer is a unique utility because it allows you to browse AD for information on, for
example, the replication cycle and replication partners. Figure 4.19 shows the Replication
Information pane, which displays the last successful replication cycle for each domain controller,
replication partners, and any errors that occurred during replication.
Chapter 4

Figure 4.19: DirectoryAnalyzer allows you to view the replication cycle and replication partners for each
domain controller.
Using DirectoryAnalyzer, you can monitor and track the replication process for errors. If a
problem occurs, the utility will issue an alert to indicate what type of problem has occurred. You
can double-click the alert to see more detailed information, then use the knowledge base to find
troubleshooting methods to help you solve the problem. The Current Alerts screen displays the
more recent alerts that have been logged for replication (see Figure 4.20).

136
Chapter 4

Figure 4.20: The Current Alerts screen in DirectoryAnalyzer allows you to view the most recent alerts for the
replication process.
You can also view the replication-related alerts that have been stored in the Alert History file in
DirectoryAnalyzer. To display these alerts, on the Current Alerts screen, choose Reports, Alert
History. On the Report page, select one of the report options to specify what alerts you want to
include. Then select Preview to display the report on the screen. You can print the report or
export it to a file. Figure 4.21 illustrates an Alert History report.

137
Chapter 4

Figure 4.21: Using DirectoryAnalyzer, you can produce a report of replication-related alerts.
Monitoring via Auditing
Ive already mentioned the important role that auditing can play in the troubleshooting process.
Windows includes built-in auditing mechanisms, which log auditing events to the Windows
event logs.
Setting up Auditing
Auditing is controlled on a per-object basis within the domain. To view this feature, you can, for
example, open Active Directory Users and Computers, and right-click a domain. Select
Properties from the context menu, select the Security tab, then click Advanced, and select the
Auditing tab.
If the Security tab isnt visible, ensure that Advanced Features is selected on the consoles View
menu, then try again.
As Figure 4.22 shows, you can define which actions generate audit messages. To fully enable
auditing, audit all success and failure events for the special Everyone group. Although doing so
will produce the maximum amount of useful information for troubleshooting, it will create a log
entry for practically every event that occurs within AD. This volume of events can quickly
overfill the Security event log and create more data than you can readily utilizea downside of
ADs auditing capabilities.

138
Chapter 4

Figure 4.22: Configuring auditing in AD.
Reviewing Auditing Messages
Use the Security event log to review audit messages. Figure 4.23 shows the log and the various
messages that it has accumulated. You can use the log viewers normal tools to filter or search
for specific types of messages, although in many cases, finding messages related to a particular
problem can be challenging.

139
Chapter 4

Figure 4.23: Viewing auditing events in the Security event log viewer.
Using ChangeAuditor for Active Directory
There are several problems with ADs built-in auditing capabilities. First, the audit log can be
erased by an administrator, leading to the possibility of a rogue administrator making changes
and then deleting the evidence. Second, ADs auditing occurs on a per-domain controller basis;
thus, to troubleshoot a problem, you must examine the logs on every domain controller in your
environment to search for clues. This process is too inefficient for most administrators to bother
with, which is perhaps why auditing has never become a popular troubleshooting tool. Finally,
not every possible change within AD can be effectively audited using ADs built-in capabilities,
which were designed for security auditing rather than troubleshooting.
ChangeAuditor collects events in real-time and forwards them to a central database; thus, the
inefficiencies in ADs built-in auditing capabilities can be bypassed. ChangeAuditor also
organizes events and makes filtering for specific events much easier.

140
Chapter 4
For example, suppose you were having a problem with replication to a specific site. There are, of
course, a number of potential causes for this problem. However, if replication used to work, then
you can expect that one or more changes have occurred in order to create the problem. This
change(s) might simply be a change in network connectivity (such as a WAN link thats down),
or it could be a configuration change. To begin the troubleshooting process, ChangeAuditor
gives you a good first place to look; as Figure 4.24 shows, you can quickly spot configuration
changessuch as the addition of a new site linkwhich might be having an impact on your
environments AD replication.

Figure 4.24: Spotting configuration changes can lead to a solution more quickly.
ChangeAuditor can also spot changes to the registry and file systemchanges that Windows
built-in auditing functionality can log, but can also be incredibly difficult to detect in the
enormous mass of data that the Security log would contain were you to audit events related to
those OS components.

141
Chapter 4

142
Summary
Before you can accurately troubleshoot AD, you must be able to effectively monitor it for
problems. Thus, you must be able to monitor the directory that has been distributed across
domain controllers on the network. You can do so by using the monitoring tools described in this
chapter. These tools allow you to watch the directory components individually and as they
interact with each other. For example, you can monitor the domain controllers, the domain
partition, the GC partition, the operations masters, and the replication process and topology.
Monitoring these components ensures the health of the directory as a system. In addition, you
can use auditing tools to perform effective and efficient troubleshooting of AD problems
saving time and energy that can be better spent on other administrative tasks.
Chapter 5

143
Chapter 5: Troubleshooting Active Directory and
Infrastructure Problems
Troubleshooting AD means analyzing and identifying problems that occur in your AD network
and subsequently repairing them. Troubleshooting a production AD environment can often be
difficult because its dynamic and complex by nature, but there are techniques and tools
available to make the job easier. In this chapter, youll learn how to apply these techniques and
tools and develop an AD network-troubleshooting methodology.
The troubleshooting process primarily involves isolating and identifying a problem. Few
problems are difficult to solve once you know exactly what is going wrong and where.
Troubleshooting, in general, is more an art born out of experience than an exact science. Your
approach to solving a problem can depend largely on the specifics of your directory, system, and
network. This chapter outlines some common techniques and approaches that you can use to help
troubleshoot and maintain your AD implementation.
Following a Specific Troubleshooting Methodology
When you troubleshoot AD, follow a specific methodology of diagnosing and troubleshooting
problems in the system. This methodology is a set of steps you can follow to identify situations,
diagnose problems, and repair AD components. The first step of this methodology is a set of
questions that you can use to identify particular situations or problems:
Is network communication working?
Does the name resolution work?
Are the domain controllers responding?
Are the operations masters working?
Is the replication topology working?
When a problem doesnt exhibit the characteristics of a typical failure, and when monitoring
tools fail to provide enough information to isolate the problem, the next step is to try to eliminate
pieces of the system until you end up with a small, predictable failure. As mentioned earlier, use
the process of elimination to rule out as many technologies and dependencies as possible. Even if
the problem seems overly complex at first, you can simplify it by eliminating all of the
possibilitiesone by one.
Chapter 5

144

Building a Wolf-Proof Fence
Experienced troubleshooters often follow, even unconsciously, an excellent methodology that is a good
practice to emulate. Simply ask yourself How can I find a wolf in Siberia? The wolf is the problem that is
occurring in AD, and Siberiaa large, uncharted territoryis the vast array of things that could be wrong.
The answer to the question, of course, is to build a wolf-proof fence. Down the middle of Siberia, to be
specific: You know the wolf is on one side or the other. In AD troubleshooting terms, you implement this
methodology by asking yourself one question that will definitively rule out one class of problems or the
other.
For example, lets suppose that replication isnt working on a particular domain controller. Broadly
speaking, two things could be wrong: Network connectivity is messed up, or AD itself is messed up.
Pinging another domain controller by name will eliminate or confirm the entire category of network
connectivity: If the ping works, you can focus on AD itself, having eliminated half of your potential
problems; if the ping doesnt work, you can focus on network connectivity. The ping becomes your wolf-
proof fence, narrowing the problem to one side of Siberia or the other.
With one side out of the way, you divide and conquer the remaining half. If youre down to network
connectivity, you might try pinging another domain controller by IP address, thus eliminating or confirming
the realm of name resolution as the problem. You continue breaking the problem into halves until you
come to the right answer. The trick is in knowing one test, in each case, that will eliminate or confirm
roughly half the potential problems.
Troubleshooting Network Connectivity
You can troubleshoot network connectivity in a number of ways. For example, you can
Test that the hardware youre using has network connectivity
Test that IP addresses are correct by using the IP Configuration (IPCONFIG) utility
Test that TCP/IP connections are working using the PING utility
Perform other troubleshooting tests by using DirectoryAnalyzer
Testing for Network Connectivity
The first step toward identifying and diagnosing AD problems is to verify that each domain
controller and user workstation has network connectivity. At a minimum, you need to check that
your domain controllers hardware is functioning correctly, including the computers local area
network (LAN) adapters, drivers, cables, and network hub. For example, if you look in the
Network and Dial-up Connections screen under Control Panel, and the Local Area Connection
icon is marked with a red X, the network cable isnt connected.
Figure 5.1 shows that the domain controller has a local area connection problem. Because the
domain controllers cable isnt connected to the network, there is a simple solution to the
problem: reconnect the cable.
Chapter 5

Figure 5.1: A red X on the Local Area Connection icon indicates that the network cable is disconnected from
your domain controller.
Testing the IP Addresses
Another method of checking network connectivity on the LAN is to make sure that the IP
addresses are correct. To perform an IP check, use the IPCONFIG utility. IPCONFIG allows you
to view and modify the domain controllers IP configuration details on the command line. It also
checks that the default gateway is on the same subnet as the local computers IP address. For
Domain Name System (DNS) dynamic updates, you can use IPCONFIG to register the
computers entries in the DNS service.
To view a computers TCP/IP configuration, type the following command in a Command Prompt
window on the domain controller or workstation:
i pconf i g / al l
The default display shows only the IP address, subnet mask, and default gateway for each
adapter bound to TCP/IP. Figure 5.2 shows an unsuccessful TCP/IP configuration and network
connection.

145
Chapter 5

Figure 5.2: An unsuccessful TCP/IP configuration and network connection, shown by using IPCONFIG.
Listing 5.1 shows a well-connected LAN. Notice that the IP addresses are displayed with
appropriate values.
C: > i pconf i g / al l
Wi ndows Ser ver 2003 I P Conf i gur at i on
Host Name . . . . . . . . . . . . : cx266988- S
Pr i mar y DNS Suf f i x. . . . . . . . : company. com
Node Type . . . . . . . . . . . . : Hybr i d
I P Rout i ng Enabl ed. . . . . . . . : No
WI NS Pr oxy Enabl ed. . . . . . . . : No
Sear ch Li st . . . . . . . . . . . : company. com

Et her net adapt er Local Ar ea Connect i on:
Connect i on- speci f i c DNS Suf f i x. . : company. com
Descr i pt i on . . . . . . . . . . . : Net el l i gent 10/ 100TX PCI Embedded
UTP Coax Cont r ol l er
Physi cal Addr ess. . . . . . . . . : 00- 80- 5F- A9- C0- 74
I P Addr ess. . . . . . . . . . . . : 10. 0. 0. 10
Subnet Mask . . . . . . . . . . . : 255. 255. 0. 0
Def aul t Gat eway . . . . . . . . . : 10. 0. 0. 1
Listing 5.1: A well-connected LAN, shown by using IPCONFIG.
If you want to save the results of running IPCONFIG for further analysis, you can capture the
results in a text file. At the command line, enter the following command:
i pconf i g / ALL > <l ocal _dr i ve>: \ <t ext _f i l e. t xt >
There are many advanced features and switches available with IPCONFIG. To view the available
switches, enter the following command at the command line:
I PCONFI G / ?
If everything looks normal when you run IPCONFIG, go on to test the TCP/IP connection.

146
Chapter 5

147
Testing the TCP/IP Connection
You can test the TCP/IP connection among connected servers and workstations by using the
PING utility. PING lets you determine whether the LAN adapter and TCP/IP are working and
whether you have network connectivity to the default gateway or the Dynamic Host
Configuration Protocol (DHCP) server. In this case, you can use the PING command to test
TCP/IP connectivity among the domain controllers that support AD or on a workstation that uses
AD. You can start the PING command on one domain controller to test the connectivity to
another. When a domain controller fails to connect to the targeted computer, the PING utility
returns a Request timed out or Destination host unreachable message. This message is repeated
at least four times as PING retries the connection. In addition, the utility shows statistics
gathered during the test.
You can use the PING utility to perform a series of steps to troubleshoot connectivity problems
among domain controllers. The first test is called the loop-back address test, which verifies
whether TCP/IP is working on the local computer. To perform this test on the local computer,
type the following command in the Command Prompt window. (Instead of using 127.0.0.1, you
can use the keyword localhost.)
PI NG 127. 0. 0. 1
If the PING command fails on the loop-back address test, check the TCP/IP configuration
settings and restart the local domain controller.
After you verify that TCP/IP is configured properly and the PING loop-back address test
succeeds, you need to test the local TCP/IP address of the local domain controller. To do so, type
the following command:
PI NG <l ocal _TCP/ I P_addr ess>
If the PING test for the local address fails, restart the domain controller and check the routing
tables by using the ROUTE PRINT command at a command prompt on the computer. The
ROUTE PRINT command displays the current IP address assigned to the local computer plus all
of the active and persistent network routes. This command allows you to view and troubleshoot
the network configurations that exist at the time that the command is executed.
After youve verified that the local address is working properly, use the PING command to check
the communication to the other domain controllers in the same location or subnet. For example,
you can check connectivity to the other domain controllers on the same subnet as follows:
PI NG <domai n_cont r ol l er 1_addr ess>
In the PING statements, the domain controller address is represented as the domain name (that is,
COMPANY.COM) or the IP address of the domain controller (that is, 10.0.0.10). If
communication among the domain controllers on the local subnet fails, you need to check that
each computer is operational and that the network hubs and switches are working properly. If the
domain controllers are separated by a wide area network (WAN) connection, you need to ping
the default gateways that route the TCP/IP traffic among WAN locations.
Start by pinging the IP address of your default gateway. If the PING command fails for the
gateway, you need to verify that the address for the default gateway is correct and that the
gateway (router) is operational.
Chapter 5

148
Next, ping the IP address of the remote domain controllers on the remote subnet as follows:
PI NG <r emot e_domai n_cont ol l er 1_addr ess>
In the PING statements, the remote domain controller address is represented as the domain name
(that is, REMOTE.COMPANY.COM) or the IP address of the domain controller (that is,
20.0.0.20). If the PING command fails, verify the address of each remote domain controller and
check whether each remote domain controller is operational (generally, youll also want to ping
the IP address directly, to ensure that name resolution isnt causing the ping to fail). In addition,
check the availability of all of the gateways or routers between your domain controller and the
remote one.
In addition to pinging the domain controllers, you need to ping the IP address of the DNS server.
If this command fails, verify that the DNS server is operational and the address is correct.
Performing Other Troubleshooting Tests Using DirectoryAnalyzer
You can perform several other tests of network connectivity in AD using DirectoryAnalyzer
from NetPro. You can test the network connection, view the current status and name, query IP
addresses, and perform server lookups. You can use DirectoryAnalyzer to perform the following
troubleshooting tests:
Domain controller connectivity test
Domain connectivity test
Site connectivity test
Each performs a different type of connectivity test among the domain controllers in specific AD
domains and sites.
Domain Controller Connectivity Test
The domain controller connectivity test allows you to test the connectivity between a selected
domain controller in the forest and one or more target domain controllers. This test is useful for
testing communications among any domain controllers in the forest. To perform this test, choose
Troubleshoot, DC Connectivity. The Test Domain Controller Connectivity dialog box appears, in
which you can select the domain controllers involved in the test.
First, select the source domain controller from the Source list. Next, select the destination
domain controller(s) that the source will communicate with during the test by selecting the check
box to the left of each domain controller in the Destination list. Then click Start Test. Figure 5.3
shows the results of running the domain controller connectivity test.
Chapter 5

Figure 5.3: Running the domain controller connectivity test to troubleshoot the communication path among
domain controllers in the forest.
After the test is completed, the results are displayed at the bottom of the dialog box:
DestinationShows the name of each destination domain controller you selected.
TestShows the type of test that was performed. The type of test varies according to the
services that have been assigned to the domain controller.
TimeShows the amount of time (in milliseconds) it took to perform each test. If a test
is performed in less than 10 milliseconds, its displayed as < 10 ms; otherwise, the actual
time is displayed.
ResultShows whether a test was successful. If the test failed, this column displays a
brief description of why.
Domain Connectivity Test
The domain connectivity test allows you to test the connectivity of a domain controller in a
selected domain against domain controllers in the destination domain(s). To perform this test,
choose Troubleshoot, Domain Connectivity. The Test Domain Connectivity dialog box appears,
in which you can select the domains involved in the test.
First, select the source domain/domain controller from the Source list. Next, select the
destination domain(s) that the source domain/domain controller will communicate with during
the test by selecting the check box to the left of each domain in the Destination list. Then click
Start Test. Figure 5.4 shows the results of running the domain connectivity test.

149
Chapter 5

Figure 5.4: Running the domain connectivity test to troubleshoot the communication between the domain
controller in the source domain and the domain controllers in the destination domain.
After the test is completed, the results are displayed at the bottom of the dialog box:
DestinationShows the name of each destination domain/domain controller you
selected.
time is displayed.
Site Connectivity Test
The site connectivity test allows you to test the connectivity of a domain controller in a selected
site against domain controllers in the destination site. To perform this test, choose Troubleshoot,
Site Connectivity. The Test Site Connectivity dialog box appears, in which you can select the
site and domain controllers involved in the test.
First, select the source site/domain controller from the Source list. Next, select the destination
site(s) that the source domain/domain controller will communicate with during the test by
selecting the check box to the left of each name in the Destination list. Then click Start Test.
Figure 5.5 shows the results of running the site connectivity test.

150
Chapter 5

Figure 5.5: Running the site connectivity test to troubleshoot the communication between a site/domain
controller and the domain controllers in the destination site.
After the test is completed, the results are displayed at the bottom of the dialog box.
DestinationShows the name of each destination site/domain controller you selected.
time is displayed.

151
Chapter 5

152
Troubleshooting Name Resolution
DNS is the name resolution system used to locate computers and domain controllers in AD. For
example, a workstation or member server finds a domain controller by querying DNS. If you
have problems connecting to AD and youve successfully tested network connectivity, a name-
resolution problem may exist. For example, if you cannot find domain controllers or network
resources when you perform queries, it might mean that DNS domain names arent being
resolved to IP addresses.
Understanding Name Resolution
The first step in identifying and diagnosing AD name-resolution problems is to review how the
Windows computer registers names and locates domain controllers. For example, whenever you
start a domain controller, it can register two types of names:
A DNS domain name with the DNS service
If the computer has Network Basic Input/Output System (NetBIOS) enabled, a NetBIOS
name with Windows Internet Name Service (WINS) or with another transport-specific
service
The DNS resource records (RRs) registered by the domain controllers in AD include multiple
service (SRV) records, address (A) records, and CNAME (canonical name) records, all of which
identify the domain controllers location in a domain, site, and forest. When a domain controller
is started, the Netlogon service registers these records. It also sends DNS dynamic-update
queries for the SRV records, A records, and CNAME records every hour to ensure that the DNS
server always has the proper records.
When you use AD-integrated zones, the DNS server stores all of the records in the zone in AD.
To run AD-integrated zones, the DNS service must be running on the domain controller. Its
possible that a record is updated in AD but hasnt replicated to all DNS servers hosting the zone.
This occurrence might cause consistency problems. By default, all DNS servers that load zones
from AD poll the directory at set intervals (every 5 minutes, but you can change this setting) to
update the directorys representation of the zones.
In WS2K3, not every domain controller contains your AD-integrated DNS zone. DNS can be
configured to replicate this information only to those domain controllers that are actually acting as
DNS servers. Doing so reduces the amount of replication required to keep DNS current on every
domain controller.
Checking that DNS Records Are Registered
If DNS records for a domain controller arent registered on the DNS server, no other domain
controller or workstation can locate the domain controller. There are a few ways that you can
check for this.
Chapter 5
Using Event Viewer
If DNS records arent registered in DNSfor example, if the DNS client has problems
dynamically updating DNS recordserrors are recorded in the System Log in Event Viewer.
Figure 5.6 shows how the System Log tracks DNS errors in Event Viewer.

Figure 5.6: Using Event Viewer to track DNS errors that occur on the selected domain controller.
If the domain controller is a DNS server, an additional log tracks all of the DNS basic events and
errors for the DNS service on the server. For example, the DNS Server log monitors and tracks
the starts and stops for the DNS server. It also logs critical events, such as when the server starts
but cannot locate initializing datafor example, zones or boot information stored in the registry
or (in some cases) AD. Figure 5.7 shows how you can access the DNS Server log in Event
Viewer.

153
Chapter 5

Figure 5.7: Using the DNS Server log in Event Viewer to track the errors for all DNS events that occur on a
domain controller that supports a DNS server.
Using PING
Another simple method for checking whether DNS records have been registered is to determine
whether you can look up the names and addresses of network resources by using the PING
utility. For example, you can check the names using PING as follows:
PI NG COMPANY. COM
If this command works, the DNS server can be contacted by using this basic network test. Even
if the command doesnt work, the PING utility will show you the results of the name resolution
process. For example, typing:
PI NG SERVER2
Might create the output:
Pi ngi ng ser ver 2 [ 192. 168. 0. 103] wi t h 32 byt es of dat a:
Proving that the name Server2 was resolved to an IP address; you can check to make sure the IP
address is correct.
Using NSLOOKUP
Next, you need to verify that the DNS server is able to listen to and respond to basic client
requests. You can do so by using NSLOOKUP, a standard command-line utility provided in
most DNS-service implementations, including Windows. NSLOOKUP allows you to perform
query testing of DNS servers and provides detailed responses as its output. This information is
useful when you troubleshoot name-resolution problems, verify that RRs are added or updated
correctly in a zone, and debug other server-related problems.

154
Chapter 5

155
To test whether the DNS server can respond to DNS clients, use NSLOOKUP as follows:
NSLOOKUP
Once the NSLOOKUP utility loads, you can perform a test at its command prompt to check
whether the host name appears in DNS. Listing 5.2 shows the output you can receive.
> company. com
Ser ver : ns1. company. com
Addr ess: 250. 45. 87. 13

Name: company. com
Addr ess: 250. 65. 123. 65
Listing 5.2: A sample command and output received by using NSLOOKUP.
The output of this command means that DNS contains the A record and the server is responding
with an answer: 250.65.123.65. Next, verify whether this address is the actual IP address for your
computer. You can also use NSLOOKUP to perform DNS queries, examine the contents of zone
files on the local and remote DNS servers, and start and stop the DNS servers. If the record for
the requested server isnt found in DNS, you receive the following message:
The comput er or DNS domai n name does not exi st
Checking the Consistency and Properties of the DNS Server
You can check the consistency and view the properties of DNS servers, zones, and RRs by using
another command-line utility called DNSCMD. WS2K3 provides DNSCMD as a command-line
interface for managing DNS servers. You can use this tool to script batch files, help automate the
management and updating of existing DNS server configurations, and set up and configure new
DNS servers on your network. DNSCMD also allows you to manually modify DNS server
properties, create zones and RRs, and force replication between a DNS servers physical memory
and the DNS database and data files. You can use DNSCMD for most tasks that you can perform
from the DNS console, such as:
Creating, deleting, and viewing zones and records
Resetting server and zone properties
Performing routine administrative operations, such as updating, reloading, and refreshing
the zone
Writing the zone back to a file or to AD
Pausing and resuming the zone
Clearing the cache
Stopping and starting the DNS service
Viewing statistics
You can install DNSCMD by copying it from the \Support\Tools folder located on the OS CD-
ROM. For help in using the command, enter the following at a command prompt:
DNSCMD / ?
Chapter 5

156
When the DNS Server Doesnt Resolve Names Correctly
Windows includes a caching DNS-resolver service, which is enabled by default. For
troubleshooting purposes, this service can be viewed, stopped, and started like any other
Windows service. The caching resolver reduces DNS network traffic and speeds name resolution
by providing a local cache for DNS queries.
How the Caching DNS-Resolver Service Works
When a name is submitted to DNS, if the resolver is caching names, it first checks the cache. If
the name is in the cache, the data is returned to the user. If the name isnt in the cache, the
resolver queries the other DNS servers that are listed in the TCP/IP properties for each adapter. It
does this in the following order:
6. The resolver checks the local hosts file (located by default in
C:\Windows\System32\drivers\etc) to see whether the required name is listed. The
localhost address, for example, resolves to 127.0.0.1 through use of the hosts file, not a
DNS server.
7. If the name isnt in the hosts file, the resolver sends the query to the first server on the
preferred adapters list of DNS servers and waits one second for a response.
8. If the resolver doesnt receive a response from the first server within one second, it sends
the query to the first DNS servers on all adapters that are still under consideration and
waits 2 seconds for a response.
9. If the resolver doesnt receive a response from any server within 2 seconds, it sends the
query to all DNS servers on all adapters that are still under consideration and waits
another 2 seconds for a response.
10. If it still doesnt receive a response from any server, it sends the query to all DNS servers
on all adapters that are still under consideration and waits 4 seconds for a response.
11. If it still doesnt receive a response from any server, the resolver sends the query to all
DNS servers on all adapters that are still under consideration and waits 8 seconds for a
response.
12. If the resolver receives a positive response, it stops querying for the name, adds the
response to the cache, and returns the response to the client. If it doesnt receive a
response from any server by the end of the 8 seconds, it responds with a time-out. Also, if
it doesnt receive a response from any server on a specified adapter, it responds for the
next 30 seconds to all queries destined for servers on that adapter with a time-out and
doesnt query those servers.
The resolver also keeps track of which servers answer queries more quickly, and it might move
servers up or down on the search list based on how quickly they respond. In addition, the
resolver also caches negative responses. If the resolver is able to successfully reach a domain
controller, but that domain controller is unable to resolve the requested name to an IP address,
the result is a negative response. So long as that negative response remains in the cache, the
resolver will not try to resolve the address again. You can clear the cache by running the
following from a command-line:
I PCONFI G / FLUSHDNS
Doing so forces the resolver to start over the next time any name needs to be resolved.
Chapter 5

157
Using Other Techniques
A typical problem occurs when a DNS server doesnt resolve names correctly and provides
incorrect data for queries. For example, if an administrator changed the IP address on a domain
controller but DNS wasnt properly updated, DNS would supply the incorrect IP address to
clients.
When working with Windows and DNS entry changes, you may notice that the DNS server has
stale RRs because they havent been updated recently. Thus, if there have been previous lookups
or name-resolution activity, the DNS server doesnt see the changes to the RRs. (The server
caches DNS information from previous lookups so that subsequent lookups are fast.) The typical
method of fixing this problem is to restart the server.
You can also fix this problem by using the IPCONFIG command. Entering the following
command allows you to view the current list of DNS entries that the server has cached:
I PCONFI G / di spl ayDNS
Entering the following command allows you to refresh all DHCP leases and re-register DNS
names. (Wait 5 minutes for the DNS entries in the cache to be reset and updated with the RRs in
the servers database.)
I PCONFI G / r egi st er DNS
You can also use the IPCONFIG command to dump all of the DNS cache entries.
I PCONFI G / f l ushDNS
Its worth noting that the DNS server should eventually refresh the cache because each entry has
a Time-To-Live (TTL) associated with it. TTL indicates a length of time used by other DNS
servers to determine how long to cache information for a record before discarding it. For
example, most RRs created by the DNS server service inherit the minimum (default) TTL of 1
hour from the start-of-authority (SOA) RR; this prevents overly long caching by other DNS
servers. TTL is automatically decremented and eventually expires and disappears or is flushed
from the cache.
For an individual RR, you can specify a record-specific TTL that overrides the minimum
(default) TTL inherited from the SOA RR. You can also use TTL values of zero (0) for RRs that
contain volatile data not to be cached for later use after the current DNS query is completed.
Another problem that may occur is that the DNS server doesnt resolve names for computers or
services outside your immediate network. For example, the DNS server may not resolve names
for computers located on an external network or the Internet. If a DNS server fails to resolve a
name for which its not authoritative, the cause is usually a failed recursive query. Recursion is
used in most DNS configurations to resolve names that arent located in the configured DNS
domain.
For recursion to work correctly, all DNS servers used in the path of the recursive query must be
able to respond to and forward correct data. If the DNS server fails a recursive query, you need
to review the servers configuration. By default, all Win2K DNS servers have recursion enabled.
You can disable recursion using the DNS console to modify advanced server options. In
addition, recursion might be disabled if the DNS server is configured to use forwarders.
Chapter 5

158
Troubleshooting the Domain Controllers
You have several options for troubleshooting domain controllers. Before I discuss them, though,
its important to review the AD database and its associated files.
Understanding the AD Database and Its Associated Files
AD is stored on each domain controller in a local database. The database exists as a domain
database and, married with the directory services, performs authentication services to users and
applications. The domain controllers replicate their data with each other to ensure that copies of
the domain database on other domain controllers are current and accurate.
The AD database is implemented on an indexed sequential access method (ISAM) table manager
that has been referred to as J et. The table manager is called the Extensible Storage Engine
(ESE). The ESE database is managed on each domain controller by the ESE.DLL file. The
database is a discrete transaction system that uses log files to ensure integrity; it uses support
rollback to ensure that the transactions are committed to the database.
The following files are associated with AD:
NTDS.DITThe main database file, ntds.dit grows as the database fills with objects and
attributes. However, the log files have a fixed size of 10 megabytes (MB). Any changes
made to the database are also made to the current log file and to the DIT file in the cache.
Eventually the cache is flushed. If a computer failure occurs before the cache is flushed,
ESE uses the log file to complete the update to the DIT file.
By default, the AD database is stored in <DRIVE>\WINNT\NTDS\NTDS.DIT. The log files for
the directory database are stored in the same directory by default. Their purpose is to track the
changes in the directory database, and they can grow to be quite large. Give all the room you can
to the log files; for example, you can place the log files on different disk drives than the database
file to reduce disk contention on a single drive.
EDB.LOG and EDBXXXXX.LOGEDB.LOG is the current log file for AD. When a
change is made to the database, its written to this file. When EDB.LOG becomes full of
database transactions, its renamed to EDBXXXXX.LOG, where XXXXX starts at 00001
and continues to increment using hexadecimal notation. AD uses circular logging, which
constantly deletes old log files. If you view the directory files at any time, youll notice
the EDB.LOG file and at least one or more EDBXXXXX.LOG files.
EDB.CHKStores the database checkpoint, which identifies the point at which the
database engine needs to replay the logs. This file is typically used during recovery and
initialization.
RES1.LOG and RES2.LOGPlaceholders designed to reserve the last 20MB of disk
space on the disk drive. Saving disk space gives the log files sufficient room to shut down
gracefully if other disk space is consumed.
Chapter 5

159
To manage the database, Windows provides a garbage-collection process designed to free space
in the AD database. This process runs on every domain controller in the enterprise with a default
lifetime interval of 12 hours. The garbage-collection process first removes tombstones from
the database. Tombstones are remains of objects that have been deleted. (When an object is
deleted, its not actually removed from the AD database. Instead, its marked for deletion at a
later date. This information is then replicated to other domain controllers. When the time expires
for the object, the object is deleted.) Next, the garbage collection-process deletes any
unnecessary log files. Finally, it launches a defragmentation thread to claim additional free
space.
Above the directory database is a database layer that provides an object view of the database
information by applying the schema to the database records. The database layer isolates the
upper logical layers of the directory from the underlying database system. All access to the
database occurs through this layer instead of allowing direct access to the database files. The
database layer is responsible for creating, retrieving, and deleting the individual database records
or objects and associated attributes and values.
In addition to the database layer, AD provides a directory service agent (DSA), an internal
process in Windows that manages the interaction with the database layer for the directory. AD
provides access using the following protocols:
Lightweight Directory Access Protocol (LDAP) clients connect to the DSA using LDAP
Messaging Application Programming Interface (MAPI) clients connect to the directory
through the DSA using the MAPI remote procedure call (RPC) interface
Windows clients that use NT 4.0 or earlier connect to the DSA using the Security
Account Manager (SAM) interface
AD domain controllers connect to each other during replication using the DSA and a
proprietary RPC implementation
Comparing Directory Information
When you want to compare directory information on domain controllers or directory partitions,
you can use theDSASTAT utility. DSASTAT detects and examines the differences among a user-
defined scope of objects on two domain controllers. It retrieves capacity statistics such as
megabytes per server, objects per server, and megabytes per object class. For example, you can
use DSASTAT to compare all users in the SALES Organizational Unit (OU) in the
COMPANY.COM domain with those in another directory partition by specifying the following:
DSASTAT - S: Company1; Company2 - B: OU=SALES, DC=COMPANY, DC=COM -
GCATTRS: ALL - SORT: TRUE - T: FALSE - P: 16 - FI LTER:
( &( OBJ ECTCLASS=USER) ( ! OBJ ECTCLASS=COMPUTER) )
In this example, you can determine whether both domain controllers agree on the contents of the
OU=SALES,DC=COMPANY,DC=COM subtree. DSASTAT detects objects in one domain and
not the other (for example, if a creation or deletion hasnt replicated) as well as differences in the
values of objects that exist in both. This example specifies a base search path at a subtree of the
domain. In this case, the OU name is SALES. The filter specifies that the comparison is
concerned only with user objects, not computer objects. Because computer objects are derived
from user objects in the class hierarchy, a search filter specifying OBJ ECTCLASS =USER
returns both user and computer objects.
Chapter 5

160
DSASTAT also allows you to specify the target domain controllers and additional operational
parameters by using the command line or an initialization file. DSASTAT determines whether
domain controllers in a domain have a consistent and accurate image of their own domain.
In addition, DSASTAT compares the attributes of replicated objects. You can use it to compare
two directory trees across replicas in the same domain or, in the case of a Global Catalog (GC),
across different domains. You can also use it to monitor replication status at a much higher level
than monitoring detailed transactions. In the case of GCs, DSASTAT checks whether the GC
server has an image that is consistent with the domain controllers in other domains. DSASTAT
complements the other replication-monitoring tools, REPADMIN and REPLMON, by ensuring
that domain controllers are up to date with one another.
First: What Changed?
The first thing you probably always ask yourself when a problem occurred is what changed?
After all, left to itself, AD will almost always continue working just fine. Change is required to
cause a problem. That change might be an incorrect configuration implemented by another
administrator, or it might be a change caused by corrupted data within the database (corruption
that might result from dropped network information or even corrupted disk files). Although
errors such as corruption are difficult to find, most problems are caused by configuration
changes, which is where auditing of some kind comes into play.
By configuring your Windows domain controllers to perform auditingboth success and
failureof as many actions as possible, youll have a list of everything that has changed on each
domain controller. When a problem occurs, you can start by reviewing what has changed and
evaluating how each change might have resulted in the problem youre troubleshooting. The
problem with Windows auditing, as Ive mentioned before, is that it produces a torrent of
information that can be difficult to sift through.
Tools such as Microsoft Operations Manager (MOM) can help sift through the event logs and
call your attention to entries that have relevance to a current problem. Third-party tools such as
NetPro ChangeAuditor for Active Directory can help, too, by pinpointing certain types of
changeslike changes to ADs configurationand showing you both the before and after
values of a configuration. This before and after view can be critical for determining whether a
given change had something to do with a particular problem.
Analyzing the State of the Domain Controllers
The next step in troubleshooting and repairing problems with AD on the domain controller is to
verify that the directory portion is running without errors. The Domain Controller Diagnostic
(DCDIAG) utility allows you to analyze the current state of the domain controllers in a domain
or forest. It automatically performs the analysis and reports any problems with a domain
controller. DCDIAG requires a separate installation of the Support Tools from the Windows CD-
ROM; by default, its installed in \Program Files\Support Tools.
DCDIAG is intended to perform a fully automatic analysis with little user intervention. Thus, you
usually dont need to provide too many parameters to it on the command line. DCDIAG doesnt work
when run against a Windows workstation or serverits limited to working only with domain
controllers.
Chapter 5

161
DCDIAG consists of a set of tests that you can use to verify and report on the functional
components of AD on the computer. You can use this tool on a single domain controller, a group
of domain controllers holding a domain partition, or across a site. When using DCDIAG, you can
collect either a minimal amount of information (confirmation of successful tests) or data for
every test you execute. Unless youre diagnosing a specific problem on only one domain
controller, I recommend that you collect only the severe errors for each one.
DCDIAG allows you to run the following tests to diagnose the status of a domain controller:
Connectivity testVerifies that DNS names for the domain controller are registered. It
also verifies that the domain controller can be reached by using TCP/IP and the domain
controllers IP address. DCDIAG checks the connectivity to the domain controller by
using LDAP and checks that communications can occur by using an RPC.
Replication testChecks the replication consistency for each of the target domain
controllers. For example, this test checks whether replication is disabled and whether
replication is taking too long. If so, the utility reports these replication errors and
generates errors when there are problems with incoming replica links.
Topology integrity testVerifies that all domain controllers holding a specific partition
are connected by the replication topology.
Directory partition head permissions testChecks the security descriptors for proper
permissions on the directory partition heads, such as the schema, domain, and
configuration directory partitions.
Locator functionality testVerifies that the appropriate SRV RRs are published in DNS.
This test also verifies that the domain controller can recognize and communicate with
operations masters. For example, DCDIAG checks whether the locator can find a primary
domain controller (PDC) and GC server.
Inter-site health testIdentifies and ensures the consistency of domain controllers among
sites. To do so, DCDIAG performs several tests, one of which identifies the inter-site
topology generator and identifies the bridgeheads for each site. This test determines
whether a bridgehead server is functioning; if not, the utility identifies and locates
additional backup bridgeheads. In addition, this test identifies when sites arent
communicating with other sites on the network.
Trust verification testChecks explicit trust relationshipsthat is, trusts between two
domain controllers in the forest. DCDIAG cannot check transitive trusts (Kerberos V5
trust relationships). To check transitive trusts, you can use the NETDOM utility.
For more information about the NETDOM utility, refer to the resource kit documentation or The
Definitive Guide to Windows 2000 and Exchange 2000 Migration (Realtimepublishers), a link to which
can be found at http://www.realtimepublishers.com. You can download the WS2K3 resource kit from
http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-
b18c4790cffd&displaylang=en.
Chapter 5

162
Diagnose replication latencies testAnalyzes incoming replications and watches for
delays or preemption of a higher-priority job. If the replication process is delayed or
preempted, latencies have occurred that slow the process. This problem typically occurs
because a higher-priority task hasnt relinquished the computers processor or because a
large number of replication requests or tasks are pending. New replication tasks are
delayed because the domain controller is overloaded with replication requests.
Replication of trust objects testChecks whether the computer account object has been
replicated to all additional domain controllers in the domain. It also checks whether the
DSA object has been replicated to all replicas of the configuration directory partition.
File Replication Service (FRS) testVerifies that FRS has started successfully on all
domain controllers. If it hasnt, this test delays the NETLOGON service from advertising
that domain controller.
Critical services check testVerifies that these key services are running: FRS, Inter-site
Messaging Service, Kerberos Key Distribution Center Service, Server Service,
Workstation Service, Remote Procedure Call Locator Service, Windows Time Service,
Distributed Link Tracking Client Service, Distributed Link Tracking Server Service, and
NETLOGON service. You can also use DCDIAG with the /repairmachineaccount
command-line switch, which re-creates the domain controllers machine account if it has
been accidentally deleted.
Using NTDSUTIL
The Directory Services Management utility (NTDSUTIL.EXE) is a command-line utility included
in Windows that you can use to troubleshoot and repair AD. Although Microsoft designed the
utility to be used interactively via a command-prompt session (launched simply by typing
NTDSUTIL at any command prompt), you can also run it by using scripting and automation.
NTDSUTIL allows you to troubleshoot and maintain various internal components of AD. For
example, you can manage the directory store or database and clean up orphaned data objects that
were improperly removed.
You can also maintain the directory service database, prepare for new domain creations, manage
the control of the FSMOs, purge meta data left behind by abandoned domain controllers (those
removed from the forest without being uninstalled), and clean up objects and attributes of
decommissioned or demoted servers. At each NTDSUTIL menu, you can type help for more
information about the available options (see Figure 5.8).
Chapter 5

Figure 5.8: Viewing a list of available commands in the utility and a brief description of each.
Locating the Directory Database Files
Before you use the NTDSUTIL utility to carry out troubleshooting and integrity checking on the
AD database, you can use its Info command to determine the location and size of the directory
database files. The Info command:
Reports the free space for all disks installed on the domain controller
Reads the registry keys and associated location of the AD database files
Reports the size of each of the database files, log files, and other associated files
Before you perform this check, you must either run NTDSUTIL after having booted the domain
controller via the special Directory Service Restore mode Safe Boot option or set the
environment variable SAFEBOOT_OPTION to a value of DSREPAIR under a normal boot of
Windows (for example, via the command SET SAFEBOOT_OPTION=DSREPAIR).
To execute the Info command, select Start, Programs, Accessories, Command Prompt. In the
Command Prompt window, type
NTDSUTI L
then press Enter.

163
Chapter 5
At the ntdsutil prompt, enter the word
f i l es
The utility responds by displaying a file maintenance prompt. The following commands have
been entered and displayed to this point:
C: \ >SET SAFEBOOT_OPTI ON=DSREPAI R
C: \ >NTDSUTI L
nt dsut i l : f i l es
f i l e mai nt enance:
At the file maintenance prompt, enter the word
i nf o
to display the location and sizes of AD database files, log files, and other associated files. Figure
5.9 shows the output of this command on a domain controller.
This command works identically on Win2K and WS2K3, and can be used in mixed-version
environments with no problems.

Figure 5.9: Using the info command in NTDSUTIL to display the location and size of AD database files.
Using NTDSUTIL, you can relocate or move AD database files from one location to another on the
disk or move the database files from one disk drive to another in the same domain controller. You can
also move just the log files from one disk to another to free space for the data files (see Moving the
AD Database or Log Files later in this chapter).

164
Chapter 5

165
Checking for Low-Level Database Corruption
One of the first items you need to check when troubleshooting a domain controller in AD is that
the underlying database is functioning properly. To do so, you can use NTDSUTILs Integrity
option to detect any low-level database corruption of the directory files. The Integrity option
checks that the headers for the database are correct and that all of the internal database tables are
functioning and consistent with each other.
Before you perform a low-level database-integrity check, you need to start the domain controller
in Directory Service Restore mode. To do so, restart the domain controller. When youre
prompted, press F8 to display the Advanced Options menu. Select Directory Service Restore
mode and press Enter, then log on using the Administrator account and password that you
assigned during the DCPROMO process.
To run the NTDSUTIL Integrity option, select Start, Programs, Accessories, Command Prompt.
In the Command Prompt window, type
NTDSUTI L
then press Enter.
At the ntdsutil prompt, enter the word
f i l es
The utility responds by showing you the file maintenance category. The commands to this point
appear in the Command Prompt window as follows:
I : >NTDSUTI L
i nt egr i t y
to start the low-level database check on the domain controller. (The Integrity command reads
every byte of the directory data file and displays the percentage of completion as a graph.
Depending on the size of your database and the type of hardware youre using for the domain
controller, this process can take a considerable amount of time.) Figure 5.10 shows the results of
examining the low-level database structures in AD.
Chapter 5

Figure 5.10: Using the Integrity option in NTDSUTIL to examine the AD database on a domain controller.
To troubleshoot and repair the AD database, you can use the Integrity option only while the domain
controller is in Directory Service Restore mode.
Checking for Inconsistencies in the Database Contents
In addition to using NTDSUTIL to verify that the AD database is functioning properly, you can
use it to help you check the consistency of the contents of the AD database. The option in
NTDSUTIL that performs a contents check is the Semantic Checker. The Semantic Checker
option differs from the Integrity option in that the Semantic Checker addresses the contents
(objects and attributes) of the directory database, not just its low-level structures.

166
Chapter 5

167
When you run the Semantic Checker, it performs the following checks:
Reference Count CheckCounts the number of references in the database tables and
matches the results with the values that are stored in the data file. This operation also
ensures that each object has a globally unique identifier (GUID) and distinguished name
(DN). For a previously deleted object, this operation ensures that the object has a deleted
time and date but doesnt have a GUID or DN.
Deleted Object CheckEnsures that the object has a time and date as well as a special
relative distinguished name (RDN), given when the object was originally deleted.
Ancestor CheckEnsures that the DN tag is equal to the ancestor list of the parent
could also be stated as a check that the DN of the object minus its RDN is equal to its
parents DN.
Security Descriptor CheckEnsures that there is a valid descriptor and that the
discretionary access control list (DACL) isnt empty.
Replication CheckVerifies that there is an up-to-dateness vector in the directory
partition and checks to see that every object has meta data.
Like the Integrity option described earlier, you can run the Semantic Checker option only when
the domain controller is in Directory Service Restore mode. To run in this mode, restart the
domain controller. When youre prompted, press F8 to display the Advanced Options menu.
Select Directory Service Restore mode and press Enter, then log on using the administrator
account and password that you assigned during the DCPROMO process.
To run the Semantic Checker option, select Start, Programs, Accessories, Command Prompt. In
the Command Prompt window, type
NTDSUTI L
then press Enter. At the ntdsutil prompt, type
semant i c dat abase anal ysi s
then press Enter. Next, type
ver bose on
This command displays the Semantic Checker. To start the Semantic Checker without having it
repair any errors, type
go
To start it and have it repair any errors that it encounters in the database, enter
go f i xup
The commands to this point appear in the Command Prompt window as follows:
I : >NTDSUTI L
nt dsut i l : semant i c dat abase anal ysi s
semant i c checker : ver bose on
Ver bose mode enabl ed.
semant i c checker : go
Figure 5.11 shows the results of using the NTDSUTIL Semantic Checker.
Chapter 5

Figure 5.11: Using the NTDSUTIL Semantic Checker option to check the consistency of the contents of the
directory database.
Again, the output of this command will be identical on Win2K and WS2K3, making it easier for
administrators working in mixed-version environments.
Cleaning Up the Meta Data
The NTDSUTIL program allows you to clean up the meta data that is left behind after a domain
controller is demoted. The utility that you use to demote a domain controller is the DCPROMO
utility (DCPROMO.EXE). This utility is used to promote a server to a domain controller and
demote a domain controller to a member server.
As part of the demotion process, DCPROMO removes the configuration data for the domain
controller from AD. This data takes the form of an NTDS Settings object, which exists as a child
to the server object in the Active Directory Sites and Services Manager and is located in AD as
the following object:
CN=NTDS
Set t i ngs, CN=<ser ver _name>, CN=Ser ver s, CN=<si t e_name>, CN=Si t es, CN=C
onf i gur at i on, DC=<domai n>. . .
The attributes of the NTDS Settings object contain values about the domain controllers
replication partners, naming contexts, whether the domain controller is a GC server, and the
default query policy. The NTDS Settings object is also a container that may have child objects
that represent the replication partners. This data is required for the domain controller to
synchronize quickly but is retired upon demotion. If the NTDS Settings object isnt properly
removed when the domain controller is demoted, you can use the NTDSUTIL utility to manually
remove the NTDS Settings object.

168
Chapter 5

169
Before you manually remove the NTDS Settings object for any server, check that replication has
occurred after the domain controller has been demoted. Using the NTDSUTIL utility improperly can
result in partial or complete loss of AD functionality. (For a description of how to check whether
replication has occurred, see Chapter 4.)
To clean up the meta data, select Start, Programs, Accessories, Command Prompt. At the
command prompt, type
NTDSUTI L
then press Enter. At the ntdsutil prompt, type
met adat a cl eanup
then press Enter. Based on the options returned to the screen, you can use additional
configuration parameters to ensure that the removal occurs correctly.
Before you clean up the metadata, you must select the server on which you want to make the
changes. To connect to a target server, type
connect i ons
then press Enter. If the user who is currently logged on to the computer running NTDSUTIL
doesnt have administrative permissions on the target server, alternative credentials need to be
supplied before making the connection. To supply alternative credentials, type the following
command, then press Enter:
set cr eds <domai n_name user _name passwor d>
Next, type
connect t o ser ver <ser ver _name>
then press Enter. You should receive confirmation that the connection has been successfully
established. If an error occurs, verify that the domain controller you specified is available and
that the credentials you supplied have administrative permissions on the server. When a
connection has been established and youve provided the right credentials, type
qui t
then press Enter, to exit the Connections menu in NTDSUTIL. When the Meta Data Cleanup
menu is displayed, type
sel ect oper at i on t ar get
and press Enter. Type
l i st domai ns
then press Enter. A list of domains in the forest is displayed, each with an associated number. To
select the appropriate domain, type
sel ect domai n <number >
and press Enter (where <number> is the number associated with the domain of which the
domain controller youre removing is a member). The domain you select determines whether the
server being removed is the last domain controller of that domain.
Chapter 5

170
Next, type
l i st si t es
then press Enter. A list of sites, each with an associated number, is displayed. Type
sel ect si t e <number >
and press Enter (where <number> is the number associated with the site of which the server
youre removing is a member). You should receive a confirmation, listing the site and domain
you chose. Once you receive a confirmation, type
l i st ser ver s i n si t e
and press Enter. A list of servers in the site, each with an associated number, is displayed. Type
sel ect ser ver <number >
and press Enter (where <number> is the number associated with the server you want to remove).
You receive a confirmation, listing the selected server, its DNS host name, and the location of
the servers computer account that you want to remove.
After youve selected the proper domain and server, type
qui t
to exit the current NTDSUTIL submenu. When the Meta Data Cleanup menu is displayed, type
r emove sel ect ed ser ver
and press Enter. You should receive confirmation that the server was removed successfully. If
the NTDS Settings object has already been removed, you may receive the following error
message:
Er r or 8419 ( 0x20E3)
The DSA obj ect coul dn t be f ound
Type
qui t
at each menu to quit the NTDSUTIL utility. You should receive confirmation that the connection
disconnected successfully.
Chapter 5

171
Moving the AD Database or Log Files
There are several common problems that occur with AD that all stem from the same source: low
disk space. These problems may surface as any of a number of error messages in the Windows
event logs. The following list highlights the most common of these errors along with their
associated symptoms and solutions.
The following error message may occur when you start AD on a domain controller:
Lsass. exe - Syst emEr r or
Di r ect or y Ser vi ces coul d not st ar t because of t he f ol l owi ng
er r or : Ther e i s not enough space on t he di sk. Er r or St at us:
0xc000007f . Pl ease cl i ck OK t o shut down t hi s syst emand r eboot
i nt o Di r ect or y Ser vi ce Rest or e Mode, check t he event l ogs f or
mor e det ai l ed i nf or mat i on.
When this error occurs, the following events are recorded in the event logs for the directory
service on the domain controller and can be viewed by using Event Viewer:
Event I D: 1393
At t empt s t o updat e t he Di r ect or y Ser vi ce dat abase ar e f ai l i ng
wi t h er r or 112. Si nce Wi ndows wi l l be unabl e t o l og on user s
whi l e t hi s condi t i on per si st s, t he Net l ogon ser vi ce i s bei ng
paused. Check t o make sur e t hat adequat e f r ee di sk space i s
avai l abl e on t he dr i ves wher e t he di r ect or y dat abase and l og
f i l es r esi de.
Event I D: 428
NTDS ( 272) The dat abase engi ne i s r ej ect i ng updat e oper at i ons due
t o l ow f r ee di sk space on t he l og di sk.
The following warning message is recorded in the System Log of the domain controller
and can be viewed by using Event Viewer:
Event I D 2013:
The D: di sk i s near i ng Capaci t y. You may need t o del et e some
f i l es.
If the disk drive runs out of disk space, AD wont start up. Windows attempts to avoid this
situation, but it can occur if you ignore warnings about low disk space in the System Log or if
you run large scripts against AD for mass directory imports. To resolve the problem of having no
disk space, you can either make space available on the same disk drive or move AD to a separate
drive. The first method requires you to simply reduce the number of files or folders on the same
disk drive as the directory database.
If you want to move the AD database to another drive on the domain controller, you can use the
NTDSUTIL utility to move either the database file or the database log files. This method is ideal
when you cannot move data to another drive to free space. If all drives are at capacity, you might
need to install an additional hard disk in the domain controller.
Before you move the directory database file or log files, you need to start the domain controller
in Directory Service Restore mode. To do so, restart the domain controller. When youre
prompted, press F8 to display the Advanced Options menu. Select Directory Service Restore
Mode and press Enter, then log on using the administrator account and password that you
assigned during the DCPROMO process.
Chapter 5

172
To move the directory database file or log files, locate the drive containing the directory and log
files. The directory database (NTDS.DIT) and log files are located in the NTDS folder on the
root drive by default. (However, the administrator may have changed their locations during the
DCPROMO process.) Next, select Start, Programs, Accessories, Command Prompt. In the
NTDSUTI L
then press Enter. At the ntdsutil prompt, enter the word
f i l es
The utility displays the file maintenance category. The commands to this point should appear as
follows:
I : >NTDSUTI L
i nf o
to display the location of the AD database files, log files, and other associated files. Note the
location of the database and log files.
To move the database files to a target disk drive, type the following command at the ntdsutil
prompt:
MOVE DB TO %s ( wher e %s i s t he t ar get f ol der on anot her dr i ve)
To move the log files to a target disk drive, type the following command at the ntdsutil prompt.
(The target directory where you move the database file or log files is specified by the %s
parameter. The Move command moves the files and updates the registry keys on the domain
controller so that AD restarts using the new location.)
MOVE LOGS TO %s ( wher e %s i s t he t ar get f ol der on anot her dr i ve)
To quit NTDSUTIL, type
qui t
twice to return to the command prompt, then restart the domain controller normally.
Completely back up AD on the domain controller before you execute the Move command. In addition,
back up AD after you move the directory database file and log files; restoring the directory database
will then retain the new file location.
Repairing the AD Database
You can use the NTDSUTIL Repair feature to repair the AD database file. However, you should
use it only as a last resort for recovering the databaseif a valid backup is available, always use
it first to restore the data. The reason is that repairing the directory database doesnt always work
correctly. For example, if a database file is corrupt, using the NTDSUTIL Repair feature may not
restore all objects and attributes. In fact, in some cases, there is a risk that using the Repair
feature will cause further data to be lost.
Chapter 5
To repair the AD database file, select Start, Programs, Accessories, Command Prompt. In the
NTDSUTI L
then press Enter. At the ntdsutil prompt, enter the word
f i l es
The utility displays the file maintenance category. At the file maintenance prompt, enter the
word
r epai r
The commands to this point should appear as follows:
I : >NTDSUTI L
f i l e mai nt enance: r epai r
As soon as the repair operation has completed, run the NTDSUTIL Semantic Checker on the
database. Figure 5.12 shows the results of using the NTDSUTIL Repair option.

Figure 5.12: Using NTDSUTIL as a last resort to repair the directory database files.

173
Chapter 5

174
ADcheck: A Free AD and Windows Network Diagnostic Tool
Although Windows and its resource kit provide some basic tools for performing troubleshooting tasks,
they arent especially easy to use. NetIQ provides an excellentand freeutility for performing a host of
AD diagnostic and troubleshooting tasks. ADcheck provides five essential categories of Windows
diagnostics:
Test Domain ControllerChecks the availability of the domain controller, validates DNS records (for
example, SRV RRs), and binds to the domain controller to verify AD status
List Domain ControllersLists each domain controller along with its name, availability, Active
Directory Service Interfaces (ADSI) scripting location, and site location
List Operations MastersLists FSMO role holders, compares them with an internal best practices list,
and recommends changes when necessary
Test ReplicationChecks domain replication topology and displays diagnostic information about
replication partners
Show Domain Controller StatusProvides summaries of the status of domain controllers, including
replication errors and partners, AD site analysis, and charts that show recommended changes to the
placement of domain controllers.
ADcheck is also capable of generating some very detailed reports, each of which shows potential causes
for problems as well as the problems themselves. For some reports, it also compares the current
configuration with an internal best practices guideline and may recommend changes. Given that its
completely free, this tool is something that no Windows network administrator should be without. You can
download ADcheck from http://www.netiq.com/adcheck/download.asp.
Troubleshooting Secure Channels and Trust Relationships
When a Windows system joins a domain, a computer account is created. Whenever the system
starts after that, it uses the password for that account to create a secure channel with the domain
controller for its domain. Requests sent on the secure channel are authenticated, and sensitive
information (such as passwords) is encrypted, but the channel isnt integrity-checked, and not all
information is encrypted.
There are many reasons why a domain controller cannot communicate on a secure channel. For
example, the user or domain controller may not have the appropriate access permissions or trust
relationships. You can test the status of secure channels and trust-relationship links using the
Resource Kits NLTEST command-line utility.
To validate access to resources in a trusting domain, the trusting domain controller establishes a
secure channel with a domain controller in the trusted domain. Pass-through authentication then
occurs over this secure channel. However, in WAN environments, the trusted domains domain
controllers may be dispersed over a wide variety of fast and slow links. If a fast link is
unavailable when the trusting domain controller wants to establish a secure channel, the secure
channel may be established with a domain controller over a slow link. Even when the fast link is
reestablished, pass-through authentication may occur over the slow link to the trusted domains
domain controller.
The mechanism for establishing a secure channel is very similar to the normal user-logon
process. That is, the trusting domain controllers send out logon requests to all known domain
controllers in the trusted domain. The trusting domain controllers then set up a secure channel
with the first trusted domain controller that responds to this request.
Normally, this method is preferred because the first domain controller to respond to a logon
request is typically the controller that is located across the fastest communication link. However,
Chapter 5

175
if that link is down or the fast domain controller is unavailable, a domain controller over a
slower link may respond first, and all pass-through authentications occur over the slow link.
There is a built-in mechanism in Windows that tracks how long authentication takes over the
existing secure channel. If pass-through authentication takes longer than 45 seconds, that fact is
noted. If two such authentications exceed that limit, a rediscovery process begins, the current
secure channel is broken, and the trusting domains PDC once again sends out logon requests to
all known trusted domain controllers. However, because this mechanism tracks only those
communications that last longer than 45 seconds, users may see a 40-second delay every time
they attempt to use a resource without a secure-channel reset taking place.
You can run the NLTEST utility on the trusting domain controller to break and re-initialize a
secure channel (for example, when the secure-channel password was last changed) and obtain
information about an existing trust relationship. You can also use NLTEST to restart the
discovery process for a new trusted domain controller. The syntax of NLTEST is:
NLTEST / sc_quer y: <account _domai n>
Where <account_domain> is the name of the trusted domain. This command returns the name of
the trusted domain controller with which the trusting domain controller has a secure channel. If
that domain controller is unacceptable, use the following syntax:
NLTEST / sc_r eset : <account _domai n>
Troubleshooting the Operations Masters
The operations masters in AD perform single-master operations for the forest and domains and
are officially called Flexible Single Master Operations (FSMOs). Several operations in the
directory have single-master operationsoperations such as updating the schema, creating new
domains in a forest, issuing new blocks of relative IDs (RIDs), and supporting domains and
clients that are running NT 4.0 and earlier.
The forest has two operations masters that manage certain forest-wide single-operation activities,
and each domain has three operations masters that manage certain domain-wide activities. For
example, a forest with two domains would have eight operations masters: two for the forest and
three domain-specific operations master roles in each domain. The five FSMO roles are:
Schema masterForest-wide and one per forest
Domain naming masterForest-wide and one per forest
Relative ID (RID) masterDomain-specific and one for each domain
Primary domain controller (PDC) emulatorDomain-specific and one for each domain
Infrastructure masterDomain-specific and one for each domain.
Because the operations masters are assigned to specific domain controllers in the forest and
domains and are critical to the operation of AD, your first step to troubleshoot each operations
master is to use the domain-controller troubleshooting techniques described in Troubleshooting
the Domain Controllers earlier in this chapter. Once youre assured that the domain controller
itself is operating properly, you can turn your attention to the operations masters.
Chapter 5

176
When Operations Masters Fail
If a domain controller holding a FSMO (operations role) master fails, major network problems
are almost guaranteed to ensue. The following sections explore a list of the various operations
master roles, their functions, and the effects of losing them.
Schema Master
If the domain controller holding the forest-wide schema master role fails, you or your directory
administrators wont be able to modify or extend the AD schema. Schema modifications
typically occur when you install directory-enabled applications such as management utilities that
rely on the directory for information. These applications try to modify or extend the current
schema with new object classes, objects, and attributes. If the applications being installed cannot
communicate with the domain controller that has been designated as the schema master,
installation will fail.
The schema master solely controls the management of the directory schema and propagates
updates to the schema to the other domain controllers as modifications occur. Because only
directory administrators are allowed to make changes, the schema operations master isnt visible
to directory users and doesnt affect them.
Domain Naming Master
If the domain naming master role holder in a forest fails, you lose the ability to add and remove
domains in the forest. When a new domain is created or deleted from the forest structure, the
domain controller that has been designated as the domain naming master is contacted and
verifies that the change operation can be completed.
The domain naming master is the only domain controller that controls the creation and deletion
of domains, and it propagates the changes to the other domain controllers as necessary. Because
only directory administrators are allowed to make structural domain changes to the forest, the
domain naming operations master isnt visible to directory users and doesnt affect them.
RID Master
If the domain controller that stores the RID master role fails or stops communicating, domain
controllers in the same domain cannot obtain the RIDs they need. (RIDs are unique security
IDs.) Domain controllers use RIDs when the domain controllers create users, groups, computers,
printers, and other objects in the domain; each object is assigned a RID. The RID master role
allocates blocks of RIDs to other domain controllers in its domain. As I mentioned at the
beginning of this section, there is only one RID master role per domain.
If a domain controller has remaining (unassigned) RIDs in its allocated block, the RID master role
doesnt need to be available when new object accounts are created.
Chapter 5

177
Infrastructure Master
If the domain controller that stores the infrastructure master role fails, a portion of AD wont
function properly. The infrastructure master role controls and manages the updates to all cross-
domain references, such as group references and security identifier (SID) entries in access
control lists (ACLs). For example, when you add, delete, or rename a user who is a member of a
group, the infrastructure master controls the reference updates. There is always only one
infrastructure master role in each domain in a forest.
Because only one domain controller is assigned to perform this role, its important that it doesnt
fail. However, if it does, the failure is not visible to network users. In fact, its visible to only
directory administrators when theyve recently moved or renamed a large number of object
accounts. In addition, having one domain controller assigned to this role can be a big security
problem.
If you force a transfer of the infrastructure master role from its original domain controller to another
domain controller in the same domain, you can transfer the role back to the original domain controller
after youve returned it to production.

It is strongly recommended that you not put the infrastructure master role on any domain controller
that is also acting as a GC server, unless you have only one domain in your forest. For more
information about FSMO placement rules and best practices, see Microsoft Product Support Services
article 223346, at http://support.microsoft.com.
PDC Emulator
If the PDC emulator fails or no longer communicates, users who depend on its service are
affected. These are down-level users from NT 4.0, Window 98, and Windows 95. The PDC
emulator is responsible for changes to the SAM database, password management, account
lockout for down-level workstations, and communications with the domain controllers.
If you force a transfer of the PDC emulator role from its original domain controller to another domain
controller in the same domain, you can transfer the role back to the original domain controller after
youve returned it to production.
Determining the Operations Master Role Holders Locations
An important step in the process of troubleshooting problems with operations master role holders
is identifying which domains controllers hold the various forest- and domain-wide roles. There
are actually several methods of determining the location of FSMO role holder in Windows.
Chapter 5

178
Using the DSA and Schema MMC Snap-Ins
To determine the RID master, PDC emulator, and infrastructure master FSMO role holders of a
selected domain by using Windows built-in tools, select Start, Run, type
dsa. msc
and press Enter or click OK. Right-click the selected Domain Object in the top left pane, then
click Operations Masters. Select the PDC tab to view the server holding the PDC master role,
then select the Infrastructure tab to view the server holding the infrastructure master role, and
select the RID Pool tab to view the server holding the RID master role.
Determining the forest schema master role holder is a bit trickier. To do so, select Start, click
Run, type
mmc
then click OK. On the Console menu, click Add/Remove Snap-in, click Add, double-click
Active Directory Schema, click Close, and then click OK. Right-click Active Directory Schema
in the top left pane, then click Operations Masters to view the server holding the schema master
role.
For the Active Directory Schema snap-in to be listed as an available, youll have to have already
registered the Schmmgmt.dll file. If it doesnt appear as an option, follow these steps to register it:
select Start, Run, type
regsvr32 schmmgmt.dll
in the Open box, and click OK. A message will be displayed confirming that the registration was
successful.
Determining the forests domain naming master role holder requires you to select Start, Run,
type
mmc
then click OK. On the Console menu, click Add/Remove Snap-in, click Add, double-click
Active Directory Domains and Trusts, click Close, and then click OK. In the left pane, click
Active Directory Domains and Trusts. Right-click Active Directory Domains and Trust, and
click Operations Master to view the server holding the domain naming master role in the Forest.
Although these methods certainly work, they arent necessarily the easiest. The following
sections describe some additional methods for determining FSMO role holders on your network.
Chapter 5

179
Using NTDSUTIL
NTDSUTIL is a tool included with all editions of Windows Serverit is the only tool that shows
you all the FSMO role owners. To view the role holders, select Start, click Run, type
cmd
in the Open box, then press Enter. Type
nt dsut i l
and then press Enter. Type
domai n management
connect i ons
where <server_name> is the name of the domain controller you want to view, then press Enter.
Type
qui t
sel ect oper at i on t ar get
l i st r ol es
for connected server, and then press Enter.
Using the Resource Kits Dumpfsmos.cmd
The resource kit contains a batch file named Dumpfsmos.cmd that you can use to quickly list
FSMO role owners for your current domain and forest. The .cmd file uses NTDSUTIL to
enumerate the role owners. Dumpfsmos.cmd takes a single argument, the name of the domain
controller to which it should connect when querying for FSMO locations. The usage of the
command is:
Dumpf smos <ser ver _name>
Using DCDIAG
Another method involves the use of the DCDIAG command. On a domain controller, run the
following command
dcdi ag / t est : knowsof r ol ehol der s / v
Note that the /v switch is required. This operation lists the owners of all FSMO roles in the
enterprise known by that domain controller.
Chapter 5
Using AD Replication Monitor
Another method to view the FSMO role holders is to use the AD Replication Monitor
(Replmon.exe) utility. Before you can use AD Replmon.exe, youll need to install it. The AD
Replication Monitor utility is part of the Support Tools, which are located on the Windows CD-
ROM in the \Support\Tools folder. Run the Setup.exe file in this folder to install the tools. Once
installed, you can start the AD Replication Monitor utility by selecting Start, Programs, Support
Tools, Tools, and selecting AD Replication Monitor. Once the utility is running, you can
determine the operations master role holders for the forest and domain by right-clicking
Monitored Servers, then adding one or more servers using the wizard. Next, right-click the
servers, then click Properties, and finally, select the FSMO Roles tab. The domain controllers
that hold the operations master roles are displayed under the Owner column. To test the
connectivity to each of the operations master role holders, click Query to the right of each role.
Using Third-Party Utilities
Certain third-party utilities, such as NetPros DirectoryAnalyzer and DirectoryTroubleshooter
and NetIQs ADcheck utility, provide features to determine the domain controllers acting as
FSMO role holder servers. Figure 5.13 shows an example of viewing the schema master using
DirectoryAnalyzer.

Figure 5.13: Using a third-party utility to determine which domain controller in your forest holds a particular
FSMO role.

180
Chapter 5

181
Seizing an Operations Master Role
If a domain controller holding one or more operations master roles is down during a critical time,
will be unavailable for a long time, or is permanently out of service, youll need to take steps to
force the transfer of the role(s) to another domain controller. You can accomplish this feat by
using NTDSUTIL. Forcing this type of operations master role transfer is also referred to as
seizing the role on a domain controller. However, before you decide whether to seize the role of
an operations master, be aware that doing so is a major step that should be taken only if the
affected domain controller will never be brought back online. Forcing a transfer in this case
should be a permanent action.
Once youve determined where the current operations master role holders in a domain or forest
are (using the information in the previous section), you can use the NTDSUTIL program to
transfer the operations master role from one domain controller in the forest or domain to another
in the same forest or domain. To seize an operations master role on a selected domain controller,
on the target domain controller (the domain controller that will be taking over the forest- or
domain-wide operation master role), select Start, Run. In the Open dialog box, type
NTDSUTI L
then click OK. If youre not running NTDSUTIL on the target domain controller, you need to
select and connect to it. At the ntdsutil prompt, type
connect i ons
then press Enter. Type
where <server_name> is the name of the server you want to use, then press Enter. To supply
additional credentials, type
set cr eds <domai n_name user _name_passwor d>
and press Enter. At the Server Connections prompt, type
qui t
then press Enter again. At the ntdsutil prompt, enter the word
r ol es
To seize the role on the currently connected domain controller, enter
sei ze <r ol e_t ype>
where <role_type> is one of the following: schema master, domain naming master, rid master,
infrastructure master, or pdc. (For a list of roles that you can seize, enter
?
at the FSMO Maintenance prompt or see the list of roles at the beginning of this section.)
After you seize the roles, type
qui t
then press Enter to return to the previous menu in the NTDSUTIL interface. Repeat this step
until youve exited the utility. Reboot the domain controller that seized the operations master
role to complete the role change operation.
Chapter 5

182
If the current operations master role holder domain controller is online and accessible or can be
repaired and brought back online, its recommended that you transfer the role using NTDSUTILs
transfer command rather than the seize command. For more information about seizing and
transferring FSMO roles, see Microsoft Product Support Services articles 255504 and 223787 at
http://support.microsoft.com.
Checking for Inconsistencies Among Domain-Wide Operations Masters
Another way to troubleshoot problems on operations masters is to check for inconsistencies
among the domain controllers in a domain. If the domain controllers dont report operations
masters consistently, long-term problems, such as replication problems, can arise. Several third-
party utilities are capable of detecting domain controller inconsistencies. For example, NetPros
DirectoryAnalyzer can inspect exactly what each domain controller believes are the domain-
wide master role assignments. If all domain controllers fail to report the same values for all the
operations masters, there is a problem, which the tool will report.
Figure 5.14 shows an example of using a third-party utility (NetPros DirectoryAnalyzer) to
check for operations master role holder inconsistencies. As the figure shows, the domain
controller COMP-DC-04 lists COMP-DC-01 as the owner of the PDC operations master, while
domain controller COMP-DC-O3 is the actual owner. Thus, the owner of the PDC operations
master is inconsistent across the domain controllers.

Figure 5.14: Checking for consistency of the operations masters on domain controllers.
Chapter 5
Troubleshooting the Replication Topology
When you troubleshoot replication problems and errors, its important to know who the
replication partners of a specific domain controller are and the status of replication with each
one. The following sections explore methods to gather this information.
Viewing the Replication Partners for a Domain Controller
You can view the replication partners for a specific domain controller by using two tools,
DirectoryAnalyzer and REPADMIN. When you use DirectoryAnalyzer to see replication
partners, youre viewing the replication topology for the selected domain controller in a forest,
and you can check replication consistency among replication partners. In addition,
DirectoryAnalyzer constantly checks the replication topology to ensure that its transitively
closed. If it isnt, DirectoryAnalyzer generates an alert.
Figure 5.15 shows the Replication Information tab in the Browse Directory By Site view. This
tab allows you to view the replication topology and the last successful replication cycle for each
replication partner. It also shows the replication partners and any errors that occurred during
replication.

Figure 5.15: Using DirectoryAnalyzer to view the replication partners for each domain controller.

183
Chapter 5

184
You can also use the Replication Administration (REPADMIN) utility to monitor the current
links to other replication partners for a specific domain controller, including the domain
controllers that are replicating to and from the selected domain controller. Viewing these links
shows you the replication topology as it exists for the current domain controller. By viewing the
replication topology, you can check replication consistency among replication partners, monitor
replication status, and display replication meta data. To use REPADMIN to view the replication
partners for a domain controller, enter the command
REPADMI N / SHOWREPS
Forcing Domain Controllers to Contact Replication Partners
If you detect errors when viewing the replication partners using either the DirectoryAnalyzer
utility or the REPADMIN tool, you can manually force the domain controller to contact its
replication partners and authenticate with them. Doing so is necessary to create the replication
links. You can use the following command to force contact:
REPADMI N / KCC
During normal operation, the Knowledge Consistency Checker (KCC) generates automatic replication
topology for each directory partition on the domain controllers. You dont need to manually manage
the replication topology for normal operation.
Tracking Replicated Changes
After the replication links have been re-created, future replication processes should occur
automatically at the normal scheduled time. You can check whether replication is occurring
normally among replication partners by tracking a particular replicated change. Doing so allows
you to ensure that the target domain controller is receiving the change. To perform this check,
enter the following for a specific object in AD:
REPADMI N / SHOWMETA CN=CJ OHNSON, OU=ENGI NEERI NG, DC=COMPANY, DC=COM
<domai n_cont r ol l er >
In this command, <domain_controller>is the host name of the target domain controller for
which youre tracking replicated changes for CJ OHNSON in the ENGINEERING OU in the
COMPANY.COM domain. The output from this command shows the Update Sequence Number
(USN), originating DSA, date and time, version number, and replicated attribute.
In addition to tracking replicated changes, many third-party utilities constantly evaluate replication
latency across all domain controllers. If the latency exceeds the specified threshold, the utility will
generate an administrative alert and/or generate a log entry reporting the condition.
Forcing Replication Among Replication Partners
There are several methods that you can use to initiate replication among direct replication
partners in a common name context. For each of the following methods, the source domain
controller describes the domain controller that replicates changes to a replication partner. The
destination domain controller receives the changes.
Chapter 5

185
To force replication among replication partners, you can use REPADMIN to issue a command to
synchronize the source domain controller with the destination domain controller by using the
object GUID of the source domain controller. To accomplish the task of forcing replication, you
need to find the GUID of the source server. Enter the following command to determine the
GUID of the source domain controller:
REPADMI N / SHOWREPS <dest i nat i on_ser ver _name>
You can find the GUID for the source domain controller under the Inbound Neighbors section of
the output. First, find the directory partition that needs synchronization and locate the source
server with which the destination is to be synchronized. Then note the GUID value of the source
domain controller. Once you know the GUID, you can initiate or force replication by entering
the following command:
REPADMI N / SYNC <di r ect or y_par t i t i on_DN> <dest i nat i on_ser ver _name>
<sour ce_ser ver _obj ect GUI D>
The following example shows how to run this command to initiate replication between DC1 and
DC2 of the domain partition called COMPANY.COM. The replication is forced from the source
domain controller, DC1, to the destination domain controller, DC2. To perform the replication,
use the following command:
REPADMI N / SYNC DC=COMPANY, DC=COM DC1 d2e3f f dd- b98c- 11d2- 712c-
0000f 87a546b
If the command is successful, the REPADMIN utility displays the following message:
REPLI CASYNC( ) FROM SOURCE: d2e3badd- e07a- 11d2- b573- 0000f 87a546b,
TO DEST: DC1 I S SUCCESSFUL.
Optionally, you can use the following switches at the command prompt:
/FORCEOverrides the normal replication schedule
/ASYNCStarts the replication event without waiting for the normal replication to finish
Youll typically force replication only when you know that the destination domain controller has
been down or offline for a long time. It also makes sense to force replication to a destination
domain controller if network connections havent been working for a while.
Viewing Low-Level AD Replication Status
You can troubleshoot the replication topology another way by viewing the low-level status of
AD replication. The REPLMON utility allows you to do so. Because this tool is graphically
based, you can view the replication topology in graphical form and monitor the status and
performance of replication among domain controllers.
Chapter 5

186
REPLMON provides a view only from the domain controller perspective. Like REPADMIN,
you can install it from the \Support\Tools folder on the Windows CD-ROM. REPLMON has two
options that youll find helpful when monitoring AD:
Generate Status ReportGenerates a status report for the domain controller. The report
includes a list of directory partitions for the server, the status of the replication partners
for each directory partition, and the status of any Group Policy Objects (GPOs). It also
includes the status of the domain controllers that hold the operations master roles, a
snapshot of performance counters, and the registry configuration of the server.
Show Replication TopologiesDisplays a graphical view of the replication topology.
This option can also display the properties of the domain controller and any intra-site or
inter-site connections that exist for the domain controllers.
Checking for KCC Replication Errors
Another method of troubleshooting replication problems is to check the entries that appear in the
Directory Service log in Event Viewer. Event Viewer lists errors that pertain to replication, such
as KCC errors. For example, you might see the entry (ID 1311 from event source NTDS KCC) in
the Directory Service log; it means that the Directory Service consistency checker has
determined that for changes to propagate across all sites, replication cannot be performed with
one or more critical domain controllers.
This error could also indicate that there isnt enough physical connectivity to create a spanning
tree connecting all of the sites. A spanning tree is a network algorithm that most network
switches use to build tables of media-access-control-address and port-number associations. This
behavior can occur if the KCC has determined that a site has been orphaned from the replication
topology.
One domain controller in a specific site owns the role of creating inbound replication connection
objects among bridgehead servers from other sites. This domain controller is known as the Inter-
Site Topology Generator. While analyzing the site link and site link bridge structure to determine
the most cost-effective route to synchronize a naming context between two points, it might
determine that a site doesnt have membership in any site link and therefore has no means of
creating a replication object to a bridgehead server in that site.
The first site in AD (named Default-First-Site-Name) is created automatically. It a member of
the default site link (DEFAULTIPSITELINK) that is also created automatically and used for
RPC communication over TCP/IP among sites. If you create two additional sitesfor instance,
Site1 and Site2you need to define a site link that each site is going to be a member of before
these sites can be written to AD. However, you can also edit the properties of a site link and
modify which sites reside in it. If you remove a site from all site links, the KCC displays the
error message listed earlier to indicate that a correction needs to be made to the configuration.
When the KCC generates this error message, its in a mode in which it doesnt remove any
connections. Normally, the KCC cleans up old connections from previous configurations or redundant
connections. Thus, you might find that there are extra connections during this time. The solution is to
correct the topology problem so that the spanning tree can form.
Chapter 5

187
Troubleshooting by Using Change Management
No discussion of troubleshooting AD would be complete without mentioning one of the most
important techniques available to the network administrator: change management. In any
hardware- or software-troubleshooting endeavor, one of the most important questions an
administrator can ask is: What changed to cause this problem? As youve probably learned from
your own experience, most problems dont occur in a vacuum. Rather, they develop as a result of
some change that is made or that occurs in the system. Thus, the ability to know what was
changed on the networkand whenis an invaluable troubleshooting tool.
Obtaining this type of change-management data for AD has been difficult or impossible.
Windows doesnt record such changes automatically in its event logs, and logging AD
infrastructure changes manually is cumbersome and prone to error. Even third-party AD-
management tools have been challenged in this area. Although several tools are available to
diagnose problems with and monitor real-time events related to AD infrastructure components,
the ability to analyze the progression of changes to these components over time has remained
elusive.
This situation changed recently when NetPro released the ChangeAuditor for Active Directory
tool. ChangeAuditor is unique in that it gives administrators a wide array of information about
changes to an AD network that occur over time:
Records of all AD infrastructure and configuration changes across the enterprise
A historical record of AD changes, including modifications to such key infrastructure
elements as directory structure, replication, security, and schema
An enterprise-level view of changes to the AD object population that occur over time
Information detailing who made changes
Before and after views for many changes, showing you not only that a change occurred
but also the old and new values
With this kind of information in hand, it becomes much easier to investigate the origin of a
problem and resolve it as well as to keep yourself generally in the loop about important
changes that are being made to your AD infrastructure. You can view at a glance events such as
additions or deletions to AD elements such as domains, OUs, domain controllers, groups and
Group Policy, and the AD schema, and you can view the changes to the population of these
elements over time (or at a particular time).
For example, when users at a particular site report suddenly slow network logons that began that
morning, you might analyze your change log and determine that the only domain controller
serving the domain on that site was removed by a site administrator the previous evening.
ChangeAuditor consolidates all of the collected data into a single, centralized database, and
provides convenient access to it by using a helpful reporting interface.
Its a good idea to use change-management information proactively in addition to using it reactively.
For example, you might use the object-population information to analyze and plan network capacity
and to predict future trends and infrastructure needs. This information is invaluable for management
reports and IT budget planning.
Chapter 5

188
Summary
Troubleshooting AD means identifying and analyzing problems that occur and repairing them in
the various systems. The troubleshooting process is mostly about isolating and identifying a
problem. To troubleshoot AD, you first check to see whether the domain controllers in the forest
can communicate with each other. Next, you need to ensure that AD has access to DNS and that
DNS is working properly. After you verify that DNS is working, you need to check that the
individual domain controllers and operations masters are working properly and supporting the
directory functions. Last, you need to verify that replication is working and that no consistent
errors are being generated. The ability to quickly assess what is causing a problem and
effectively develop a solution will help ensure smooth IT performance that successfully supports
the business.
Chapter 6

189
Chapter 6: Creating an Active Directory Design that You Can
Audit and Troubleshoot
When youre creating a new AD environment, youre often focused on business goals such as
How will users be organized for administration? What OUs will you need for proper application
of GPOs? Technical goals are usually another big consideration: How many GC servers will you
need? Will every office require a domain controller? Troubleshooting is rarely a consideration
during the design phase because troubleshooting isnt necessary when nothing is broken. Many
organizations dont consider auditing at the initial design stage, either, because auditing often
isnt identified as a business or technical need until the environment is up and running. Both
troubleshooting and auditing, however, should be given serious consideration during the design
phase because a properly designed AD environment can make both troubleshooting and auditing
easier and more efficient.
What if youve already designed your AD environment and have been living with it for a while?
Fortunately, few design decisions in AD are one-time or irreversible, meaning a minor
redesignthis time with troubleshooting and auditing more firmly in the front of your mind
can provide significant operational advantages.
Design Goals
Every AD design has goals such as easy user and group management, proper application of
GPOs, user response time, and so forth. In addition to these goals, you simply need to include
troubleshooting and auditing. Auditing is such an important troubleshooting toolauditing can
often tell you what has changed recently, which is often a good place to start troubleshooting
that creating an auditable design is a big part of creating a design that lends itself more readily to
troubleshooting. Some specific design goals to consider include:
PerformanceYou can overload a domain controller by placing too much of an auditing
burden on it, so your overall design needs to accommodate the level of auditing you plan
to do. If youll be auditing a lot, you might need more domain controllers so that domain
controllers can handle the auditing load as well as their normal duties. Monitoring is also
a concern: If you plan to monitor your domain controllers on a regular basis, expect that
monitoring to place some additional (albeit marginal) overhead on the domain
controllers, and design accordingly.
Access to informationYou will need to decide who will be performing auditing and
troubleshooting and ensure that information is easily accessible to those individuals. For
example, planning to use event log consolidation tools might help bring critical
information in front of the right people more quickly, making troubleshooting and
auditing more efficient and effective.
ToolsYou will undoubtedly turn to tools outside of Windows for many of your
auditing and troubleshooting needs because Windows isnt well-equipped for either task
on a large scale. Tools often bring their own requirements and overhead, and your overall
AD design should acknowledge and accommodate those needs. In other words, make
your troubleshooting and auditing tools a part of your design so that they will work more
efficiently and effectively.
Chapter 6

190
Performance Considerations
Performance often takes the biggest hit when you begin to implement auditing. The reason is not
so much that auditing a single event consumes much computing power as it is the fact that a
single domain controller can easily generate hundreds or even thousands of events per minute,
especially during busy periods like the morning rush-hour login. Carefully planning your
auditing can help minimize performance impact, and implementing additional resourcessuch
as domain controllerscan help minimize an impact on end user response times.
For example, if you have 10,000 users and 10 domain controllers, everything might be working
great. Turn on a high level of auditing, however, and all 10 domain controllers might become
just a bit slower to respond to user requests than you would prefer. Adding another couple of
domain controllers can help pick up the slack. Each domain controller will have fewer users to
handle and will generate commensurately fewer auditing events during any given period.
Why monitor performance at all? It can be a great way to spot problems before they become
severe. For example, a server with steadily declining performance might be noticed before
performance declined to a point at which the server was useless. Performance values can also
provide obvious input into troubleshooting activities, especially where AD considerations such
as replication and database utilization are concerned.
Overauditing
Overauditing is perhaps the most common mistake administrators make when implementing
auditing. You must carefully consider exactly what you need to audit, and audit only thatand
nothing more. For example, some organizations audit login or access failures because a
significant number of failures can be a clear indicator that your systems are under attack.
However, if youre not going to do anything more than a cursory, manual review of the event
logs from time to time, youre not really achieving your stated goal of detecting attacks by
auditing for these types of events. Thus, the computing power going toward logging those
failures is essentially wasted. Consider whether there is a better way to obtain the information
that auditing might provide. For example, Figure 6.1 shows the Active Directory Sites and
Services console with the root container configured to audit all success and failure events for all
users, for all possible actions.
Chapter 6

Figure 6.1: Auditing everything, for all users, by using the Active Directory Sites and Services console.
This method is a good practice from a troubleshooting perspective because youre going to get
very detailed information about everything that happens in the console. If someone adds a site
link, changes a site link bridge, and so on, an event will report that such an action took place. If a
problem occurs, you can jump right into the Event Viewer to see what changes have recently
been made. Figure 6.2 shows just such an eventsomeone has accessed a site configuration
object.

191
Chapter 6

Figure 6.2: Events showing configuration access and changes.
However, enabling this level of auditing can result in a lot of events. Although useful for
troubleshooting, the overhead created might not be worth the benefit of having these events
simply for diagnostics. Third-party tools that provide the same information can come in handy in
such situations. For example, NetPro ChangeAuditor for Active Directory collects similar
information with a bit more detail, and logs it to a separate database. The Windows event logging
system isnt involved; thus, although there is overhead involved, it is less than that required by
the Windows event logging system and it generates useful diagnostic information in the event
that you need to troubleshoot a problem. In this fashion, third-party tools can help collect useful
auditing and troubleshooting information without the need to go overboard with Windows built-
in auditing capabilities.
Overmonitoring
People dont realize how much overhead monitoring can place on a server. For example, running
System Monitor against a remote system can add a measurable amount of overhead; running it
all day, every day can reduce response times if you dont specifically plan for the monitoring in
your design and compensate for that overhead. For example, using System Monitor configured
as Figure 6.3 shows produced about a 2 percent overhead on the system being monitored. Not a
huge amount, but definitely something you want to be aware of and plan for.

192
Chapter 6

Figure 6.3: Monitoring isnt free. This chart produced about 2 percent processor overhead on the monitored
system.
This area is another in which tools other than those bundled with Windows may do a better job.
For example, Microsoft Operations Manager (MOM) provides round-the-clock monitoring, but it
does so by sampling performance counters at regular intervals rather than continuously
monitoring them and drawing graphical charts based on their values. In fact, most enterprise-
class monitoring tools from companies such as NetPro, Microsoft, Argent Software, and NetIQ
are all capable of gathering more monitoring information while producing less overhead than
Windows built-in performance monitoring tools.

193
Chapter 6

194
Design Considerations
Once youve addressed your performance concerns in your design, you can begin thinking about
how your AD design will support troubleshooting and auditing needs. Specific questionssuch
as Who will use auditing information and how?will drive specific design decisions that affect
your overall AD design.
Who Will Troubleshoot?
One of the biggest questions youll need to answer is who will be troubleshooting your AD
environment? More accurately, youll need to determine who will need access to AD
troubleshooting information.
Many organizationsparticularly those subject to regulations such as the Health Insurance
Portability and Accountability Act (HIPAA), the Sarbanes-Oxley Act, Gramm-Leach-Bliley Act,
and so forthneed to be sensitive about who has access to information. In some cases, AD
troubleshooting information might contain information that is considered confidential. Simply
making troubleshooting data available to all administrators, for example, might unnecessarily
expose this confidential information, or at least present a risk for unnecessary exposure. This
consideration can create difficulty in your design because you ideally want to make
troubleshooting information available to all technical staff members but might be constrained
from doing so as a result of these types of regulatory concerns.
Physical location can also affect your design. For example, if the individuals who perform most
of your troubleshooting are located in one office and troubleshooting information is collected
from a variety of offices, you might want a design that allows for information to be consolidated
into a location that is convenient for the centralized technical staff. If, however, your technical
staff is distributed and tends to work only with their local resources, you might want the
troubleshooting information to be distributed so that it is more conveniently accessible to the
people who will be using it.
What type of troubleshooting information do you need to be concerned with? Potentially, any
data that might contribute to faster identification of a problem and its resolution:
Auditing information can help identify recent changes that might have been responsible
for a problem.
Basic documentation can provide reference and background information for narrowing a
problem or solution.
Performance information can help identify additional symptoms or root causes for a
problem.
Chapter 6

195
Windows built-in tools for AD auditing and performance monitoring arent highly centralized.
Audit events, for example, are scattered across the event logs of every domain controller;
performance information cant be readily centralized without significant overhead because
System Monitor is the only real built-in way to collect this information. Windows doesnt
provide any built-in means of centralizing network-related documentation, particularly as it
relates to changes. Third-party tools often provide much more flexibility, allowing information to
be consolidated in central databases, made accessible through Web interfaces to distributed staff
members, and so forth. For these reasons, youll often find that third-party solutions will become
an indispensable part of your overall AD design.
For example, while not strictly falling into the category of third-party, Microsoft has a tool
called Microsoft Audit Collection Service (ACS, which has not been released by Microsoft as of
this writing). The tool is an agent-based service that collects security events from multiple
servers and funnels them into a central SQL Server database for filtering, reporting, searching,
and so forth. Many third-party manufacturers offer solutions that perform a similar function;
NetIQ, for example, has several products (notably the AppManager suite) designed to collect
event log entries into a single database; MOM performs a similar task as part of its feature set.
How Will Auditing Be Utilized?
A major part of your designwhich AD events will be auditedwill be determined by how
those events will be utilized. Will auditing primarily serve a troubleshooting function or is
auditing also going to be used to perform security audits, compliance audits, and so forth? If
auditing will simply serve as a troubleshooting tool, for example, simply auditing successful
eventsmeaning events related to changes that were implementedmight be sufficient for
troubleshooting purposes. If auditing will also be used to perform security, compliance, and other
audits, you might need to collect a wider variety of events and make those events accessible to
individuals with different goals.
For example, a security auditor might not be focused on events related to changes in the AD site
structure but wants to see how often administrative accounts are used. A troubleshooter, in
contrast, might be best served by exactly the opposite information. In cases in which you will be
collecting events that at least one person or group doesnt need to see, youll need to provide
some collection and filtering capabilities to ensure that the correct events reach the right people.
Again, Windows built-in auditing capabilities fall short in this arena, and third-party tools can
be more effective. For example, Figure 6.4 shows NetPros ChangeAuditor, which can
effectively filter events by type so that both troubleshooters and auditors can access the
information that is relevant to them.
Chapter 6

Figure 6.4: Filtered events allow everyone who uses auditing information to focus on their specific job tasks
without being distracted by extraneous events.
Many tools store events in their own databases (either collecting events through their own
interfaces, as ChangeAuditor does, or consolidating Windows events as ACS does), your options
for providing this information to the people who need it are broader. You can, for example, make
auditing information available to individuals who arent administrators and might not normally
have access to, say, the security log; doing so allows you to more granularly define the security
in your environment.

196
Chapter 6

197
For How Long Will Data Be Maintained?
Troubleshooters wont often need to look at data that is more than a month or so old; changes
made that long ago will generally have already caused whatever problems they are going to
cause. However, many organizations might need to maintain auditing information for a longer
period of time to satisfy regulatory or business policy requirements. Windows auditing tool
Event Viewersimply allows logs to be manually saved to a file, which isnt an efficient means
of archiving events from multiple servers. Scripts can be used to automate this process and target
several computers; Listing 6.1, for example, is a VBScript-based script that archives the security
logs from several computers listed in a text file.
This script is designed to be saved as a file with a .WSF filename extension. You can run it from a
command line and use the /? argument to see its syntax and usage instructions. You can download
this script from the ScriptVault at http://www.ScriptingAnswers.com.
<?xml ver si on=" 1. 0" ?>
<package>
<comment >
Pr i mal Code wi zar d gener at ed f i l e.
</ comment >
<j ob i d=" l oghunt er " pr ompt =" no" >
<?j ob er r or =" f al se" debug=" f al se" ?>
<r unt i me>
<descr i pt i on>
Col l ect s secur i t y l og f i l es f r oma l i st of comput er s ( l i st ed i n a t ext
f i l e, one comput er name per l i ne) and ar chi ves t hose l ogs t o a
speci f i ed f ol der . Opt i onal l y, col l ect ed l ogs can be cl ear ed.
</ descr i pt i on>
<named hel pst r i ng=" Fi l ename l i st i ng one comput er name
per l i ne" name=" f i l e" r equi r ed=" t r ue" t ype=" st r i ng" / >
<named hel pst r i ng=" Fol der name - must exi st - wher e
l ogs shoul d be ar chi ved" name=" dest " r equi r ed=" t r ue" t ype=" st r i ng" / >
<named hel pst r i ng=" Yes or No - cl ear l og af t er
ar chi vi ng" name=" cl ear " r equi r ed=" t r ue" t ype=" st r i ng" / >
<named hel pst r i ng=" Speci f y t he pat h f or t he ar chi ve
f i l e" name=" ar chi ve" r equi r ed=" t r ue" t ype=" st r i ng" / >
<usage>
Cl ear l og f i l es af t er col l ect i on:

Loghunt er / f i l e: c: \ comput er s. t xt / dest : c: \ ar chi ve / cl ear : yes
</ usage>
</ r unt i me>
<scr i pt i d=" Loghunt er " l anguage=" VBScr i pt " >
<! [ CDATA[
' ======================================================================
'
' LogHunt er
'
' VBScr i pt by Don J ones. Copyr i ght ( c) 2004 Br ai nCor e Nevada, I nc.
' Al l Ri ght s Reser ved. Pr ovi ded wi t hout war r ant y of any ki nd; pl ease
' t est t hor oughl y bef or e usi ng i n a pr oduct i on envi r onment . The aut hor
' of t hi s scr i pt i s not r esponsi bl e f or any damages ar i si ng f r omi t s
' use, i ncl udi ng damages whi ch t he aut hor has been advi sed of .
'
Chapter 6

198
' www. Scr i pt i ngAnswer s. com- Wher e Wi ndows Admi ni st r at or s Go To
Aut omat e
'
' AUTHOR: Don J ones
' DATE : 7/ 31/ 2004
'
' COMMENT:
'
' ======================================================================

I f WScr i pt . Ar gument s. Count < 3 Then
WScr i pt . Ar gument s. ShowUsage
WScr i pt . Qui t
End I f

Di msFi l e, sFol der , bCl ear
sFi l e = WScr i pt . Ar gument s. Named( " f i l e" )
sFol der = WScr i pt . Ar gument s. Named( " f ol der " )
I f l case( WScr i pt . Ar gument s. Named( " cl ear " ) ) = " yes" Then
bCl ear = Tr ue
El se
bCl ear = Fal se
End I f

Di moFSO, oTS
Set oFSO = Cr eat eObj ect ( " Scr i pt i ng. Fi l eSyst emObj ect " )
I f Not oFSO. Fol der Exi st s( sFol der ) Then
WScr i pt . Echo " Dest i nat i on f ol der does not exi st "
WScr i pt . Qui t
End I f
I f Not oFSO. Fi l eExi st s( sFi l e) Then
WScr i pt . Echo " I nput f i l e does not exi st "
WScr i pt . Qui t
End I f

Di msCl i ent , oWMI Ser vi ce, cLogFi l es, oLogf i l e
Di mer r BackupLog, sOut f i l e
Set oTS = oFSO. OpenText Fi l e( sFi l e)
Do Unt i l oTS. At EndOf St r eam
sCl i ent = oTS. ReadLi ne
Set oWMI Ser vi ce = Get Obj ect ( " wi nmgmt s: " _
& " {i mper sonat i onLevel =i mper sonat e, ( Backup) }! \ \ " & _
sCl i ent & " \ r oot \ ci mv2" )

Set cLogFi l es = oWMI Ser vi ce. ExecQuer y _
( " Sel ect * f r omWi n32_NTEvent LogFi l e wher e " & _
" LogFi l eName=' Secur i t y' " )

For Each oLogf i l e i n cLogFi l es
sOut f i l e = oFSO. Bui l dPat h( sFol der , sCl i ent & " =" & _
Dat ePar t ( " y" , Dat e) & " - " & Dat ePar t ( " yyyy" , Dat e) & " . evt "
er r BackupLog = obj LogFi l e. BackupEvent Log( sOut f i l e)

I f er r BackupLog <> 0 Then
Wscr i pt . Echo " Coul dn' t get l og f r om" & sCl i ent
El se
WScr i pt . Echo " Got " & sCl i ent
oLogFi l e. Cl ear Event Log( )
Chapter 6

199
End I f
Loop
oTS. Cl ose
WScr i pt . Echo " Compl et e"

] ] >
</ scr i pt >
</ j ob>
</ package>
Listing 6.1: A VBScript-based script that archives the security logs from several computers listed in a text
file.
Third-party tools, which rely on more flexible databases and their own storage formats, can
generally provide more flexible long-term storage options, if needed. For example, ACS is
designed to store security events for years in a SQL Server database. If long-term event storage
is a part of your organizations needs, make sure these needs are accounted for in your AD
design.
Design Guidelines
There are specific design considerations and suggested best practices for creating an AD
environment that lends itself to troubleshooting and auditing. The following sections explore
these considerations.
Selecting Appropriate Tools
By now you should already have answered key questions that address who will need to have
access to troubleshooting information and so forth; these questions will help drive your selection
of troubleshooting tools. For example, you might decide to use tools such as MOM or an AD-
specific tool such as NetPro ChangeAuditor to collect troubleshooting information rather than
rely entirely on Windows built-in auditing capabilities and Event Viewer console. Regardless of
which tools you choose, the AD design phase is the appropriate time to consider what those tools
will require from your environment. Most higher-end tools will work best with an agent installed
on each domain controller so that events can be quickly collected and funneled into the tools
central database. You will need to test to determine how much overhead these agents require so
that you can plan your domain controller workload appropriately. If youre going to stick with
Windows Event Viewer for collecting information, do some testing to see how much overhead
is created.
Chapter 6

200
In addition, make tool selections based on your troubleshooting needs. For example, tools such
as ChangeAuditor are essentially reactive tools, providing you with information to diagnose a
problem that already exists. Other tools, such as NetPros SecurityManager, are somewhat more
proactive in nature because they continually monitor your environment for specific types of
changes, alert you to those changes, and, in some cases, restore the environment to a
preconfigured state, undoing the change. Although primarily designed to help maintain a secure
environment, these types of tools can have a valuable troubleshooting function by catching
potentially damaging changes and calling your attention to them immediately. All of these tools
have system requirements that need to be considered in your overall AD design.
At a minimum, decide on a tool set that offers the following capabilities:
Collects information regarding changes to the environment as well as any other auditing
information necessary to support business policies and regulatory compliance. Tools that
offer this functionality include the Windows Event Viewer, NetPro ChangeAuditor,
MOM, and NetIQ AppManager. You might employ a collection of tools to meet this
need: ChangeAuditor, for example, is very specific to AD, while MOM can be extended
through management packs to handle specific Microsoft server products such as
Microsoft Exchange Server and Microsoft SQL Server.
Makes the relevant information available to the correct people at the right time. Generally
speaking, this capability will involve centralizing information in a single database and
providing interfaces for various users to filter and view the information. Microsoft ACS
offers security event consolidation and reporting; MOM also helps centralize and manage
Windows events. Many third-party tools, such as ChangeAuditor, utilize their own events
and database rather than relying on Windows-generated event logs. A key purchasing
decision for any tool should be the ability to give non-administrative users access to
events (or reports of events) as needed to support their job tasks.
Collects not only audit-style events (such as the events generated by Windows for its
event logs) but also performance data. Windows lacks a robust built-in means of
collecting, consolidating, and working with performance data. Tools such as NetPro
DirectoryTroubleshooter (which is specific to AD) and NetIQ AppManager are more
adept at collecting performance-related information and making it readily accessible to
troubleshooters. When it comes to AD troubleshooting, ensure that the tool you select
presents information in a way that enhances the troubleshooting process; a tool built
specifically for AD is often able to do this better than a tool that covers Windows in a
broader sense or covers multiple server products.
Chapter 6
Configuring the Environment
Configuring the environment to support troubleshooting and auditing involves installing and
configuring whatever tools youve selected to support your troubleshooting and auditing tasks.
Properly configuring Windows is also crucial. For example, your auditing plan will probably call
for specific auditing configurations on specific areas of AD.
AD auditing is configured in three consoles: Active Directory Users and Computers, Active
Directory Domains and Trusts, and Active Directory Sites and Services. Each console allows
you to configure permissionsand auditingat various levels; youll often want to configure
auditing at the highest possible level so that auditing information is generated consistently
throughout the hierarchy. Generally, you will configure this by right-clicking the top-most object
in the consoles tree view, selecting Properties, then switching to the Security tab. On the
Security tab, click Advanced, then select the Auditing tab to display the auditing configuration,
as Figure 6.5 illustrates.
If a Security tab isnt visible, especially in Active Directory Users and Computers, select Advanced
Features from the consoles View menu and try again.

Figure 6.5: Configuring auditing on the domain in Active Directory Users and Computers.

201
Chapter 6

202
Windows doesnt require much in the way of specific configurations to enhance AD
troubleshooting; simply collecting the right events and performance data and centralizing that
information into an easily accessible database will provide all the support most troubleshooting
tasks require.
Maintaining the Proper Configuration
Ensuring that your environment remains configured for optimal troubleshooting can be difficult.
After all, Windows has tens of thousands of settings, none of which are accessible through any
one uniform methodology or technology. Third-party products generally maintain their settings
through a completely different set of techniques, such as private databases as well as by through
Windows-based techniques such as the registry.
There are tools that can help ensure that your environment remains properly configured. For
example, NetPro SecurityManager can help alert you to security-sensitive changes, such as
changes in your auditing policy. Tools such as Configuresoft Enterprise Configuration Manager
(ECM) can detect a much broader variety of configuration changes across Windows and alert
you to those changes immediately, allowing you to take corrective action. In some cases, ECM
can even undo the changes and restore your desired configuration based on a flexible system of
configuration templates and responsive actions. A regular, manual audit of your configuration
settings can also help ensure that they remain properly configured.
Regardless of the tools you use, make configuration maintenance easier by documenting your
desired configuration. Once youve decided how your tools should be configured, which events youll
audit, and so forth, having this documentation will allow a junior administrator or auditor to periodically
confirm that the environment is properly configured. In addition, this documentation will enable you to
more easily reconfigure a misconfigured environment.
Monitoring Core Areas
Your organizations security and regulatory compliance needs will tend to drive what you audit
in terms of security events; the information you collect to support troubleshooting activities will
overlap those security needs in many respects, but youll find yourself collecting a good deal of
additional data to support troubleshooting. For example, youll want to collect (and centralize
into a database, ideally) a comprehensive set of AD performance data because this data can aid
in diagnosing performance issues, replication problems, object management problems, and so
forth. NetPro DirectoryTroubleshooter has a fairly comprehensive list of AD-specific
information that it can monitor, as Figure 6.6 shows.
Chapter 6

Figure 6.6: Examining performance information related to AD.
Basically, any performance information related to AD is worth collecting, if your tools can do so
without creating an unnecessary or undesirable performance burden on your domain controllers.
Preventing Trouble
Troubleshooting, of course, begins the moment you learn of a problem. Auditing can provide
useful troubleshooting information by helping you quickly determine what has changed in your
environment because changes are a major source of problems. However, an even more effective
method is to avoid problems as much as possible.
One way to avoid problems is to avoid change. Changes cause problems simply because AD
environments are so complex: Making a change without fully considering the ramifications can
often break things or at least cause them to work less than optimally. Change, however, is the
one constant youll always have in the IT industry, so although it is a great idea to avoid
unnecessary changes, you will never be able to avoid change entirely.
The trick is to manage your change so that change is never unexpected, never ad-hoc, and never
made without being thoroughly thought through. The Information Technology Information
Library (ITILread more at http://www.ogc.gov.uk/index.asp?id=2261) is a library of best
practices for IT management and offers a lot of information about change management. ITIL
provides a set of best practices for managing change to help avoid the problems that often
accompany change.

203
Chapter 6
A Process for Change
Figure 6.7 illustrates a sample business process based upon ITIL best practices.

Figure 6.7: An ITIL-based business process for change management.

204
Chapter 6

205
The way this process works is that all changes begin with a change request being submitted and
categorized. Immediate changes are sent for immediate development rather than being reviewed,
but other changes go through a review process to consider the risks of the change, the business
benefits, and so forth. Lower-priority changes are sent through a Change Advisory Board (CAB),
which will often package approved changes for scheduled implementation (perhaps once each
month) along with a group of other approved changes. The CAB considers past change
documentation when making its analysis and tries to group changes for release so that high-risk
changes arent bundled togetherthereby presenting fewer risks at the same time. Changes are
also reviewed by an Executive Action Board (EAB), which considers areas such as business
impact. Urgent changes might bypass the CAB and go directly to the EAB, where they can be
approved for implementation more quickly or, if the EAB considers the change to be lower-
priority, queues for the CABs next review meeting.
Once approved, the change is developed by a technical staff member, then reviewed for potential
problems by a peer. Once the change is approved, it is deployed into a test environment to test
for additional potential problems. If all goes well with the test, the change is scheduled for
deployment. Prior to deployment, affected systems are backed up in case of a problem, then the
change is actually deployed to the production environment. The change is immediately reviewed
for accuracy, effectiveness, and for problems. If necessary, the change is rolled back and the
problem analysis documented for future review. At that point, the change goes back to the EAB
or CAB for further consideration. Changes that dont result in a production problem are retained,
and the environments documentation is updated to reflect the change as a part of the baseline
environment.
The purpose of this process is threefold:
To manage risk up-front by considering changes from a technical and business
perspective, and categorizing changes so that higher-priority ones receive precedence.
To manage risk by technically reviewing changes. The idea is that more eyes on the
problem will be more likely to spot potential problems before they occur.
To maintain a well-documented environment by ensuring that changes eventually become
a part of the environments overall documentation. This documentation helps to drive
decisions regarding future changes.
Tools to Manage Change
Processes are useful, but without tools to help implement them, processes can quickly be put
aside in the face of day-to-day crises and business pressures. Fortunately, several companies
offer tools to help make change management more effective. Such tools often provide a way to
automate and enforce the workflow defined in your change management process and help make
mundane tasks such as recordkeeping easier and more effective. IntaChange is a Web-based
change management tool that provides Microsoft Project integration, workflow management, and
other process-based tools to make change management more automated and efficient. As Figure
6.8 shows, IntaChange offers a calendar view of scheduled changes, making it easier for
managers and technical staff to quickly see whats coming up.
Chapter 6

Figure 6.8: IntaChanges calendar view shows upcoming changes and their details.
Another tool, Elite Change Management System provides similar functionality, including
features such as file attachments (allowing you to, for example, attach new network diagrams to
a change, indicating how the network configuration will be modified by the change) and so forth.
On an AD-specific front, NetPro offers ChangeManager. This tool not only helps track and
manage the change management process but also helps to automate the actual implementation of
changes. Changes can be tracked through each phase of the process, and you can quickly see
which changes are pending approval, have been approved but not implemented, have been
implemented, and so forth. ChangeManager incorporates a review process to help prevent
changes tat might cause problems, and most importantly, allows you to quickly identify recently
made changes. If a problem occurs, youll know exactly what changed recently, allowing you to
focus your troubleshooting efforts on the most likely cause of the problem right away.
Perhaps the most interesting feature of ChangeManagerand a real benefit of having a change
management tool that is AD-specificis the ability for lower-level administrators to have
ChangeManager invoke approved changes. This functionality allows a complex AD change to be
proposed, reviewed, and approved, all by senior administrators, while allowing a lower-level
administrator to actually have the tool implement the change at an appropriate time. The benefit
of this workflow is that senior administratorsthe ones you trust most to design accurate
changes for your environmentcan focus on design and architecture; lower-level administrators
can be trusted to implement even complex changes because ChangeManager performs the actual
implementation for them, according to the senior administrators designs.

206
Chapter 6

207
Summary
This chapter explains some of the design (or redesign) goals you should keep in mind for AD to
facilitate both troubleshooting and auditing. Weve explored performance and recordkeeping
concerns that will be an issue for regulated companies and organizations. This chapter also
introduced change management, a process that seeks to avoid problems by carefully managing
the changes that are introduced into the environment. To aid in this process, you can employ
tools that can help automate an effective change management process and make it less of a
cumbersome business process and more of a practical tool to avoid the need to troubleshoot in
the first place. Ultimately, this scenario is your goalkeep AD from having problems, and if
problems do occur, solve them as quickly as possible.
Enterprises are relying more and more on the smooth operation of AD. Of course, even the best
designed and maintained AD environment can run into problems. This guide has shown you how
to monitor AD to spot problems early as well as how to test various aspects of AD to locate
problems when they occur. As our industry matures, were finding new and creative ways to
recognize problems, prevent them from happening, and fix them when they do occur. Some of
these new techniques include auditing, which isnt immediately obvious as a troubleshooting
tool. However, the primary function of auditing is to keep track of what has changed, which is
the first step you will take in almost any troubleshooting scenario.
Other new techniques for preventing problems and reducing troubleshooting time include careful
change management and control so that only planned and tested changes are introduced into your
environment. As changes are usually the culprit, you can prevent problems by preventing
problem-causing changes.
The number of tools available to help with AD troubleshooting, change management, change
auditing, and other tasks is constantly growing. Now that AD is in its second generation, its a
more stable and mature product, and third-party manufacturers are producing robust, mature
tools to help keep AD humming along smoothly. Getting serious about troubleshooting means
putting the right management procedures in place to manage change, the right tools in place to
help, and the right know-howwhich youve got, nowto quickly address any problems that
arise.
Chapter 6

208
Content Central
Content Central is your complete source for IT learning. Whether you need the most current
information for managing your Windows enterprise, implementing security measures on your
network, learning about new development tools for Windows and Linux, or deploying new
enterprise software solutions, Content Central offers the latest instruction on the topics that are
most important to the IT professional. Browse our extensive collection of eBooks and video
guides and start building your own personal IT library today!
Download Additional eBooks!
If you found this eBook to be informative, then please visit Content Central and download other
eBooks on this topic. If you are not already a registered user of Content Central, please take a
moment to register in order to gain free access to other great IT eBooks and video guides. Please
visit: http://www.realtimepublishers.com/contentcentral/.

Definitive Guide To Active Directory Troubleshooting and Auditing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Definitive Guide To Active Directory Troubleshooting and Auditing

Uploaded by

Copyright:

Available Formats

(Sponsor Logo Here)

The Definitive Guide To

You might also like