Complete ad troubleshooting

Ask the average Windows system administrator what they think the most prominent feature of Windows 2000 is
and they will probably say "Active Directory." Why? First, Active Directory will enable them to deploy Windows-
based networks on an unprecedented scale. Second, they know that Active Directory represents a significant change
in the way they will manage network entities such as users, computers, network devices and applications. For
example, there are new user interfaces for most common management activities such as adding users and managing
printers. There are also many new system concepts, such as multi-master replication and DNS integration that
administrators must understand in order to keep their Active Directory installations healthy.
Some might ask why there are so many new concepts to learn. The answer lies in understanding both limitations of
earlier directory services and Microsoft's design goals for Active Directory. First-generation directories demonstrated
the power of standards-based repositories, but didn't support replication. By running only on a single machine,
they provided no opportunity for scale-out and became a single point of failure in the network. Second-generation
technologies added single-master replication (with read-only replicas) that scaled much better, but supported
updates only against the master. In practice, single-master models bound individual deployments to 'regions' of
continuous network connectivity. Third-generation directories added multi-master support but with important
constraints. For example, one third-generation directory service is limited, in practice, to approximately 10 update-
able replicas per partition and works best only over high-speed network connections.
Microsoft decided that, in order to scale to enterprise levels, Active Directory had to support large numbers of
geographic locations (potentially in excess of 1,000) and not be limited by slow or intermittent network connectivity.
This led to fourth-generation features in Active Directory such as sites, trees, forests, bridgehead servers, and global
catalogs. These features have enabled Active Directory to scale to unprecedented levels while remaining manageable.
At the same time, there are, as author Sean Daily notes, a lot of moving parts in the average Active Directory
deployment. Most of the time, these parts work together just fine. There will be occasions, however, when issues
arise. For example, if a replica is unable to contact any other replica for long periods of time (usually due to net-
work configuration problems) some troubleshooting will eventually be required. Then, it will be important to
understand how Active Directory's parts fit together in order to get to the root of the issue quickly.
I believe that this innovative, on-line book from NetPro and Realtimepublishers.com will prove to be a valuable
resource for any administrator who is tasked with managing an Active Directory installation. The approach to
information delivery is ideal. The book starts with important background concepts that will enable the reader to
understand the design of Active Directory and relationships between components, in a clear and concise way. Later
chapters build on this knowledge by providing step-by-step procedures for diagnosing common issues even when
the root cause of an issue may not be clear.
Most important, this book provides a methodology for proactively keeping an Active Directory installation healthy
while simultaneously enabling administrators to get to the root causes of problems quickly when they do occur.
Such a methodology can be 'worth its weight in gold' to today's systems administrators who are responsible for
keeping ever-more complex systems up and running with ever-less downtime!
Peter J. Houston Group Program Manager, Active Directory Microsoft Corporation
Redmond, Washington
March 6th, 2001
The Definitive Guide to Active Directory Troubleshooting Foreword
Foreword by Peter Houston

Chapter 1
Introducing Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
The Importance of Directories and Directory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Many Eggs, One Basket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
New Tools for New Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Meet Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
The AD Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Logical Architecture of AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Objects and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Domains, Trees and Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Organizational Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
The Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Physical Structure of AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Directory Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
The Operations Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
AD’s Backbone: DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Introduction to AD and Win2K Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
AD and Win2K Monitoring Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Change Monitoring and Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Problem Resolution, Automation and Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Chapter 2
Designing an Effective Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Active Directory’s Logical and Physical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Logical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Naming Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Physical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Designing Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Designing the Forest and Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Determining the Number of Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Setting Up and Managing Multiple Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Determining the Number of Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Designing the Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Determining the Number of Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Choosing a Forest Root Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
The Definitive Guide to Active Directory Troubleshooting table of contents
Table of Contents

Using a Dedicated Root Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Assigning a DNS Name to Each Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Using an Internet-Registered Name for the Top-Level Domian . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Using Internet Standard Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Using Locations to Name Child Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Never Using the Same Name Twice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Dividing the Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Placing the Domain Controller for Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Determining Trust Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Using Bi-Directional Transitive Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Using One-Way Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Using Cross-Link Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Designing Organizational Units for Each Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Creating OUs to Delegate Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Creating OUs to Reflect Your Company’s Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Creating OUs for Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Creating OUs to Restrict Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Designing the Sites for the Forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Creating Sites and Site Links Based on Network Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
About Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
About Site Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Creating the Site Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Using Sites to Determine the Placement of Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Using Sites to Determine the Placement of DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Chapter 3
Monitoring and Tuning the Windows 2000 System and Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Monitoring Windows 2000 Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Monitoring the Overall System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Using Task Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Using the Performance Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Events Tracked in Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Types of Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Starting Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Types of Events Logged by Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Sorting and Filtering Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Exporting Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Monitoring Memory and Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Using Task Manager to View Memory on a Domain Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Using the Performance Console to Monitor Memory on a Domain Controller . . . . . . . . . . . . . . . . . . . . .65
Available Memory Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Page-Fault Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Paging File Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
System Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

Monitoring Processors and Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Using Process Viewer to Monitor Processes and Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Using Task Manager to View Processes on a Domain Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Working with the List of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Viewing Information about Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Using the Performance Console to View Processes on a Domain Controller . . . . . . . . . . . . . . . . . . . . . . .75
% Processor Time Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Interrupts/sec Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Processor Queue Length Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Monitoring the Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Using the Performance Console to Monitor the Disk Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
% Disk Time and % Idle Time Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Disk Reads/sec and Disk Writes/sec Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Current Disk Queue Length Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
% Free Space Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Monitoring the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Using Network Monitor to Watch Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Using the Performance Console to Monitor Network Components on a Domain Controller . . . . . . . . . . . . .83
Domain Controller Network Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Network Interface Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Chapter 4
Monitoring Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Using the Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Third-Party Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
DirectoryAnalyzer from NetPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
AppManager from NetIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Built-In Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
System Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Replication Diagnostics (REPADMIN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Monitoring the AD Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Monitoring the Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Using NTDS Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Monitoring the Domain Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Using Domain Database Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Installing the Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Monitoring the Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Monitoring Operations Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Monitoring Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Using Directory Partition Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Schema Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Configuration Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Domain Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Using Directory Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Using Replication Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Chapter 5
Troubleshooting Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Following a Specific Troubleshooting Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Troubleshooting Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Testing for Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Testing the IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Testing the TCP/IP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Performing Other Troubleshooting Tests Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . .122
Domain Controller Connectivity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Domain Connectivity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Site Connectivity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Troubleshooting Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Understanding Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Checking That DNS Records Are Registered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Using Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Using PING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Using NSLOOKUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Checking the Consistency and Properties of the DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
When the DNS Server Doesn’t Resolve Names Correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
How the Caching DNS-Resolver Service Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Using Other Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Troubleshooting the Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Understanding the Active Directory Database and Its Associated Files . . . . . . . . . . . . . . . . . . . . . . .131
Comparing Directory Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Analyzing the State of the Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Using NTDSUTIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Locating the Directory Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Checking for Low-Level Database Corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Checking for Inconsistencies in the Database Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Cleaning Up the Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Moving the Active Directory Database or Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Repairing the Active Directory Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
Troubleshooting Secure Channels and Trust Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
Troubleshooting the Operations Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
When Operations Masters Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Schema Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Domain Naming Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148

Relative ID (RID) Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Infrastructure Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
PDC Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149
Determining the Operations Master Role Holders Locations . . . . . . . . . . . . . . . . . . . . . . . . . .150
Using the DSA and Schema MMC Snap-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
Using NTDSUTIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Using the Windows 2000 Resource Kit’s Dumpfsmos.cmd . . . . . . . . . . . . . . . . . . . . . . . .151
Using DCDIAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Using AD Replication Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Using Third-Party Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
Seizing an Operations Master Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
Checking for Inconsistencies among Domain-Wide Operations Masters . . . . . . . . . . . . . . . . . .153
Troubleshooting the Replication Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Viewing the Replication Partners for a Domain Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Using REPADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Forcing Domain Controllers to Contact Replication Partners . . . . . . . . . . . . . . . . . . . . . . .155
Tracking Replicated Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Forcing Replication among Replication Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Viewing Low-Level AD Replication Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Checking for KCC Replication Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Troubleshooting Using Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Chapter 6
Backing Up and Recovering Windows 2000 and Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Building a Fault-Tolerant System That Includes a Backup and Restore Strategy . . . . . . . . . . . . . . . . . . . . .161
Using the Windows 2000 Backup and Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Using the Backup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Specifying Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Specifying Advanced Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
Backing Up Using Manual Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
Maintaining System State Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
Using the Restore Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Specifying Advanced Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
Restoring Required Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
Windows Internet Naming Service (WINS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . . . . . . . . . . . . . . . . . .179
Remote Storage Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Certificate Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Internet Information Services (IIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
Active Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
SYSVOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
Creating an Emergency Repair Disk (ERD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
Options to Use When Your Server or Domain Controller Won’t Start . . . . . . . . . . . . . . . . . . . . . . . . . . . .181

Safe Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
The Recovery Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Using the Recovery Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Adding the Recovery Console to the Startup Options . . . . . . . . . . . . . . . . . . . . . . . . . . .183
Windows 2000 Setup Emergency Repair Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
Developing a Backup and Restore Strategy for Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Backing Up Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Restoring Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187
Non-authoritative Restores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Authoritative Restores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Verifying Restores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
The Active Directory Backup Bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
How It Occurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Working Around It . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Repairing a Domain Controller in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193

By Sean Daily, Series Editor
Welcome to The Definitive Guide to Active Directory Troubleshooting!
The book you now hold in your hands - or, in many cases - are reading on your screen, represents an entirely new
modality of book publishing and a major first in the publishing industry. The founding concept behind
Realtimepublishers.com was the idea of providing readers with high-quality books on today's most critical IT topics
-- at no cost to the reader. Although this may sound like a somewhat impossible feat to achieve, it is made possible
through the vision and generosity of corporate sponsors such as NetPro, who agree to bear the book's production
expenses and host the book on their website for the benefit of their website visitors.
It should be pointed out that the free nature of these books does not in any way diminish their quality. Without
reservation, I can tell you that the book you're about to read is the equivalent of any similar printed book you
might find your local bookstore (with the notable exception that it won't cost you $30 to $80). In addition to the
free nature of the books themselves, this publishing model also provides other significant benefits. For example, the
electronic nature of this eBook makes events such as chapter updates and additions, or the release of a new edition
of the book possible to achieve in a far shorter timeframe than is possible with printed books. Because we publish
our titles in "real-time" - that is, as chapters are written or revised by the author - you benefit from receiving the
information immediately rather than having to wait months or years to receive a complete product.
Finally, I'd like to note that although it is true that the sponsor's website is the exclusive online location of the
book, this book is by no means a paid advertisement. Realtimepublishers.com is an independent publishing company
and maintains, by written agreement with the sponsor, 100% editorial control over the content of our titles.
However, by hosting this information, NetPro has also set themselves apart from their competitors by providing
real value to their customers and by transforming their site into a true technical resource library - not just a place to
learn about their company and products. It is my opinion that this system of content delivery is not only of
immeasurable value to readers, but represents the future of book publishing.
As series editor, it is my raison d'être to locate and work only with the industry's leading authors and editors, and
publish books that help IT personnel, IT managers, and users to 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 do so by sending an e-mail to feedback@realtimepublishers.com,
leaving feedback on our website at www.realtimepublishers.com, or calling us at (707)539-5280.
Thanks for reading, and enjoy!
Sean Daily
Series Editor
The Definitive Guide to Active Directory Troubleshooting Introduction
eBook Introduction

The Definitive Guide to Active Directory Troubleshooting
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 medium-sized networks, employ one or
more directories within their organization. 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.
Although Microsoft’s Windows NT operating system introduced a pseudo-directory in the form of the NT Directory
Service (whose heart and soul was the Security Accounts Manager – SAM – database), this "directory" had a number
of major limitations. Among these were:
Non-hierarchical structure and namespace
NT’s directory used a flat, non-hierarchical directory structure that didn’t support the naming and structural
needs of complex organizations.
Lack of extensibility
NT’s directory stored only basic user information and couldn’t be inherently extended.
Lack of scalability
The NT directory was stored inside the NT system registry database; due to this architecture, the maximum
number of users topped out in the neighborhood of around 40,000 per domain.
Poor manageability features
Administration roles weren’t layered and couldn’t be natively delegated.
Poor directory replication performance
Because NT’s architecture was bandwidth- and network topology-ignorant, the NT operating system couldn’t
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 architecture
NT’s architecture called for a single server in each network domain – the 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.
In Windows 2000 (Win2K), NT’s successor OS, Microsoft set out to deliver a directory capable of addressing each
of these limitations. Win2K’s new directory service, dubbed Active Directory (AD), provides an industrial-strength
Chapter 1 www.netpro.com1

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 to the tens of thousands NT is capable of). 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 than was present under NT 4.0. Finally, AD also
provides a central point of access control for network users, which means users can log in once and gain access to
all network resources.
Although other directories such as Banyan’s StreetTalk and Novell’s NDS have existed for some time, many
Windows NT-centric organizations have opted to wait and use Microsoft’s entry in the enterprise directory arena
as the foundation for their organization-wide directory environment. Consequently, Win2K’s Active Directory will
represent the first foray into the larger world of directories and directory management for many organizations and
network administrators.
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 Win2K’s Active Directory to consolidate all critical company information in 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 to Active Directory
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, 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 network operating system such as Win2K and its Active Directory, this also repre-
sents 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, while at the same time
the risk of loss due to downtime is increased. Furthermore, many organizations planning Win2K migrations have
chosen to focus the majority of their preparatory efforts and budgets on issues such as legacy hardware and soft-
ware compatibility, and application interoperability under the Win2K environment. Although these are certainly
worthwhile and important considerations, they are by no means the only steps required to guarantee a successful
Win2K deployment. In addition to compatibility and capacity issues, IT departments within these organizations
must also determine what additional tools, information, and training that will be required to properly support
their Win2K network environment on a day-to-day basis.
New Tools for New Times
To effectively support Win2K networks, administrators need to engage in additional network management activi-
ties beyond those taken with previous versions of Windows 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 statistics such as server
CPU, memory, and disk utilization, as well as network connectivity statistics be monitored on an ongoing basis.
However, Win2K introduces additional components, services, and dependencies that must also be regularly moni-
tored alongside these other metrics. These elements, which collectively comprise Win2K’s core infrastructure,
include items such as domain controllers, Active Directory databases and services, the Global Catalog, intra- and
inter-site replication, site links, and DNS servers. Because Win2K and Win2K-centric applications rely heavily on
these services and components for proper network operation, network administrators must be able to guarantee
not only their general availability, but an acceptable baseline of performance as well. 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 Win2K infrastructure, IT shops will need not only Win2K-aware monitoring
and management tools, but 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.
Meet Active Directory
Of all of the elements that comprise a Win2K network, the most important by far is the Active Directory, Win2K’s
centralized directory service. However, before we delve into the specifics of Win2K and the Active Directory, let’s
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), as
well as resources such as network applications and services, security policies, and virtually any other type of object
an administrator or application wishes to store within the directory data store.
As we discussed earlier, a directory service is a composite term that includes both the directory data store as well as the
services that make the information within the directory available to users and applications. Directory services are avail-
able in a variety of different types and from different sources. Operating system directories, such as Microsoft’s Active
Directory and Novell’s NDS, are general purpose directories included with the network operating system and are
designed to be accessible by a wide array of users, applications, and devices. There are also some applications, such as
enterprise resource planning systems, human resource systems, and e-mail systems (e.g. Microsoft Exchange 5.x) that
provide their own directories for storing data specific to the functionality of those applications.
Microsoft Exchange 2000 is a notable exception to this and is completely integrated with Active Directory.
Exchange 2000’s installation process extends Active Directory’s structure to accommodate Exchange-spe-
cific data and subsequently uses AD to store its own directory information.
Active Directory is Microsoft’s directory service implementation in the Win2K Server operating system. The Active
Directory is hosted by one or more Win2K 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.
The term multi-master indicates that multiple read/write copies of the database exist simultaneously, on
each Win2K domain controller computer. Thus, each Win2K 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 is in notable contrast to NT 4.0’s single-master PDC/BDC replication topology wherein a
single domain controller, the PDC, houses a read/write copy of the database.
In addition to providing a centralized repository for network objects and a set of services for accessing those objects,
Active Directory also provides security in the form of access control lists (ACLs) on directory objects that protect
those objects from being accessed by unauthorized parties.

The AD Database
At a file system level, the Active Directory uses Microsoft’s Extensible Storage Engine (ESE) to store the directory
database. Administrators familiar with Microsoft Exchange Server may recognize this as the same database technol-
ogy used in that product. Like Exchange Server, Active Directory’s database employs transactional logging 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, Active Directory also shares Exchange’s ability to perform on-line
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 Win2K domain controller.
Although the building blocks that make up the Active Directory are largely masked by the directory’s high-level
management interfaces and APIs, the physical aspects of the directory are nonetheless an important consideration for
Win2K administrators. For example, it is critical that all volumes on domain controllers hosting the Active Directory
database and its transaction logs maintain adequate levels of free disk space at all times. For performance reasons, it
is also important that the Active Directory databases on these machines not become too heavily fragmented.
Because Active Directory is a database, this effectively turns Win2K 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 (e.g. 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, it’s important to first under-
stand AD’s logical architecture. In this section, we’ll discuss the most important concepts associated with AD, con-
cepts which form the foundation of all Win2K networks.
Objects and Attributes
Just as the primary item of storage in a file system is a file, the primary item of storage in the Active Directory is an
object. Objects can take many different forms; for example, users, computers, and printers all exist as objects with-
in 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.
AD uses an object-oriented approach to defining directory objects. That is to say there exists a hierarchy of classes,
which define the kinds of objects one can create (or instantiate, as in "creating an instance of...") within the direc-
tory. Each class has a set of attributes that define the properties associated with that class. For example, Active
Directory has a user class with attributes like First Name, Address, etc.
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, as well as other OU container objects.
Although it’s perfectly acceptable to say "create" in lieu of "instantiate" when referring to the generation of a
new object within the directory, we’ll use the latter more frequently in this book. The reason is that ‘instantiate’
is more appropriate when you consider the underlying event that actually occurs -- that being the "creation of
an instance of" an object. And, hey, let’s face it: saying ‘instantiate’ sounds a lot cooler and is more likely to
impress people (just kidding – if we really believed that we’d start throwing around words like orthogonal!)

The Schema
As you might imagine, all of the object classes and attributes discussed thus far have some kind of underlying refer-
ence that describes them -- a sort of "dictionary" for Active Directory. In Win2K parlance, this "dictionary" is
referred to as the schema. The Active Directory schema contains the definitions of all object types that may be
instantiated within the directory.
Even the Active Directory 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, let’s go back to the object-oriented
model upon which the AD schema is based. As is the case with object-oriented development environments (e.g.
C++, Java, etc.), a class is a kind of basic definition of an object. When I instantiate an 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", which has attributes
like "color," "year," "enginesize," etc. I can instantiate the class "motorcycle" and create a real object called
"Yamaha YZF600R6" with properties like "red" (for the color attribute), 2000 (for the year), and 600 (for the
motorcycle engine’s size in CCs).
Similarly, an Active Directory implementation within your enterprise is just the instantiation of the Active
Directory 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, who has properties like pass-
word, address, home directory location, etc.
You can view the AD Schema through the AD Schema Microsoft Management Console (MMC) snap-in, which is
shown in Figure 1.1.
Figure 1.1: Viewing the Active Directory Schema using the AD Schema MMC snap-in.

LDAP
One of the early design decisions that Microsoft made regarding Active Directory was the use of an efficient
directory access protocol known as the Lightweight Directory Access Protocol (LDAP). 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.
Viewing the AD Schema
Some of you may be curious at this point how to use the AD Schema MMC snap-in shown in Figure 1.1 to view the
AD schema. It’s not immediately obvious how to do this using the MMC console, since AD Schema isn’t available in
the default list of snap-ins that appears. One note of caution here: editing the schema is a potentially dangerous
activity—you need to know exactly what you’re doing and why you’re doing it. Before you make schema changes, be
sure to back up the current AD database contents and schema (e.g., by using ntbackup.exe or a third-party utility’s
System State backup option on an up-to-date domain controller).
To view the AD schema, use the Microsoft Management Console (MMC) Active Directory Schema snap-in, which
you’ll find among Win2K’s Support Tools. (You can install these tools from the Win2K CD-ROM’s support folder.) To
use this snap-in, you need to manually register the snap-in by selecting Start, Run (or entering a command-prompt
session) and typing:
regsvr32 schmmgmt.dll
You’ll 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 (i.e., mmc.exe). 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-in’s 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 it’s a global group in mixed mode
Win2K domains (i.e. those which still are still running NT 4.0 domain controllers or which have no more NT domain
controller but haven’t yet been converted to Win2K’s native mode). To use the snap-in, first register the associated
adsiedit.dll file at the command line:
regsrv32 adsiedit.dll
The ADSI Edit snap-in will be available from the MMC’s Console/Add/Remove snap-in menu. Once you’ve added
the snap-in, you can use the ADSI Edit console to make changes to AD objects and attributes.
For a more advanced discussion of the AD schema and its underlying constructs, I recommend The Definitive
Guide to Win2K Administration by Sean Daily and Darren Mar-Elia. Chapter 1 of this book describes advanced
AD schema design and management issues. You can find a link to this free eBook by Realtimepublishers.com
at http://www.realtimepublishers.com.

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 lists each of these LDAP name components and their descriptions.
Active Directory supports LDAP versions 2 and 3.
Table 1.1. LDAP name components.
Attribute Type
Domain-Component
Organizational-Unit-Name
Description
An individual element of the DNS domain name of the object’s
domain; e.g. com, org, edu, realtimepublishers, microsoft, etc.
Common-Name
Organization-Name
For example, the LDAP name for the user object for a person named "David Templeton" in the realtimepublish-
ers.com domain’s Marketing OU would be as follows:
CN=David Templeton,OU=Marketing,DC=realtimepublishers,DC=com
The above form of an object’s name as it appears in the directory is referred to the object’s distinguished name
(DN). Alternately, an object can also be referred to using its relative distinguished name (RDN). The RDN is the
portion of the DN that refers to the target object within its container. In the above example, the RDN of the user
object would simply be ‘David Templeton.
DN Abbreviation
DC
OU An organizational unit container object within an AD domain.
CN Any object other than domain components and organizational
units, such as printers, computers, users, etc.
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 Active Directory 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 Active Directory that
use Domain Components to organize the tree structure.
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 Active Directory that use Domain Components to
organize the tree structure.

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 different logical components. The first of these components is the domain. A domain
serves as the core unit in AD’s 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, Win2K
domains have unique names. However, unlike the NetBIOS-based domain names used in NT, Win2K domains use
a DNS naming structure (e.g. realtimepublishers.com or mydomain.org).
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, which defines things such as password expiration and simi-
lar security options. Domains also act as an administrative boundary, since 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 Active Directory: since all servers acting as domain controllers in a Win2K domain
replicate directory changes to one another, they contain a complete set of the directory information related to their
domain.
Win2K domain names don’t have to be Internet-registered domain names ending in Internet-legal top-level
domains, such as .com, .org, .net, etc. For example, it is possible to name domains with endings such as
.priv, .msft, or some other ending of your choosing. This of course assumes that the domain’s DNS servers
aren’t 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 Win2K domain names, you should register these names on the Internet
even if they don’t participate in the Internet DNS namespace. The reason for this 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.
Win2K’s AD design also integrates the concepts of forests and trees. A tree is a hierarchical arrangement of Win2K
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 since they share a contiguous namespace. This arrangement demonstrates the hierarchical
structure of AD and its namespace: all 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.

A forest is a collection of one or more trees. A forest can be as simple as a single Win2K domain, or more complex
such as a collection of multi-tiered domain trees.
Let's take our single-tree example scenario from earlier a step further. Assume that within this AD, the parent
organization Xcedia also has a subsidiary company with a Win2K/DNS 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, 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 global catalog (we’ll discuss the global catalog 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 a Win2K forest.
Figure 1.2: An Active Directory forest with a single tree.
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 Win2K domains.
Kerberos replaces Windows NT LAN Manager (NTLM) authentication used in Windows NT Server 4.0, as the
primary security protocol for access to resources within or across Win2K Server domains. Win2K domain
controllers still support NTLM to provide backward compatibility with Windows NT 4.0 machines.

Figure 1.3: Example of a multi-tree Active Directory 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 (i.e. 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 circum-
stances, 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 aren’t established between the two
forests but you may create explicit trusts between individual domains in different forests.
There are several resources you might find helpful when planning your organization’s AD structure and
namespace. One is The Definitive Guide to Active Directory Design and Planning, another free eBook from
Realtimepublishers.com (a link to which can be found at http://www.realtimepublishers.com). There are
also several Microsoft white papers that contain valuable information on 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 Microsoft’s Web site at
http://www.microsoft.com/windows2000/server.

Organizational Units
An organizational unit (OU) is a special container object that is used to organize other objects – such as computers,
users, and printers – within a domain. OUs can contain all of these object types, and even other OUs (this type
of configuration is referred to as nested OUs). OUs are a particularly important element of Active Directory 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.
There are a number of models used for the design of OU hierarchies within domains, but the two most
common are those dividing the domain organizationally (e.g. by business unit) or geographically.
An example of OUs within a domain is shown in Figure 1.4.
Figure 1.4: Organizational units (OUs) within a domain.
The Global Catalog
Because Active Directory is the central component of a Win2K network, network clients and servers frequently
query it. In order to increase the availability of Active Directory data on the network as well as the efficiency of
directory object queries from clients, Win2K introduces a service known as the global catalog. The global catalog is
a separate database from the Active Directory itself, and contains a partial, read-only replica of all the directory
objects in the entire AD forest.
Only Win2K servers acting as domain controllers may be configured as global catalog servers. By default, the first
domain controller in a Win2K forest is automatically configured to be a global catalog server (this can be moved later
to a different domain controller if desired; however, every Win2K forest must contain at least one global catalog). Like
Active Directory itself, the global catalog uses replication in order to ensure updates between the various global
catalog servers within a Win2K domain or forest. In addition to being a repository of commonly queried AD
object attributes, the global catalog plays two primary roles on a Win2K network:

Network logon authentication
In native-mode Win2K domains (networks where all domain controllers have been upgraded to Win2K and
the native mode election has been manually made by the administrator), the global catalog facilitates net
work logons for Active Directory-enabled clients. It does so by providing universal group membership infor
mation 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 the Active Directory (including computers,
etc.). In multi-domain networks, at least one domain controller acting as a global catalog must be available
in order for users to log on. Another situation that requires a global catalog server occurs when a user
attempts to log on with a user principal name (UPN) other than the default. If a global catalog server is not
available in these circumstances, users will only be able to login to the local computer (the one exception is
members of the domain administrators group, who do not require a global catalog server in order to log on
to the network).
Directory searches and queries
With Active Directory, read requests such as directory searches and queries by far tend to outweigh write-
oriented requests such as directory updates (e.g. by an administrator or during replication). The majority of
Active Directory-related network traffic on a Win2K network is comprised of requests from users, adminis
trators, and applications about objects in the directory. As a result, the global catalog is essential to a
Win2K infrastructure since it allows clients to quickly perform searches across all domains within a forest.
Note: Although mixed-mode Win2K domains do not require the global catalog for the network logon authentication
process, global catalogs are still important in facilitating directory queries and searches on these networks and
should therefore be made available at each site within the network.
Physical Structure of AD
Thus far, our discussion of AD has focused on the logical components of the directory’s 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 Windows NT. As is the case with
NT, a Win2K domain controller is a server that houses a replica of the directory (in the case of Win2K, the direc-
tory 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 does away with NT’s restriction that converting a domain controller to a member server or
vice-versa requires reinstallation of the server OS. In Win2K, servers may be promoted or demoted to domain
controller status dynamically (and without reinstallation) using the Dcpromo.exe domain controller promotion
wizard.

At least one domain controller must be present in a domain, and for fault tolerance reasons it’s a good idea to have
more than one domain controller at any larger site (e.g. a main office or large branch office). To prevent user logon
traffic from crossing over WAN links, you should consider putting at least one domain controller in even the small-
est of your branch offices and similar remote sites.
Directory Replication
As we’ve discussed, domain controllers are responsible for propagating directory updates they receive (e.g. 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.
The Win2K Active Directory 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 Win2K domain controller computer. Thus,
each Win2K 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.0’s
single-master PDC/BDC replication topology wherein a single domain controller, the PDC, houses a read/write
copy of the database.
AD’s replication design means that different domain controllers within the domain may hold different data
at any given time – but 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 login request. Active Directory’s
replication process has the characteristic of bringing all domain controllers up to date with each other; this
characteristic is called "convergence".
The Operations Masters
Although multi-master replication is a central feature of Active Directory and Win2K networks, the potential for
collisions and conflict between multiple servers makes this functionality inappropriate for some network operations
and roles. Win2K accommodates these special cases by electing specific domain controllers to serve as operations
masters (also referred to as flexible single master operations or FSMOs) for each of these network roles. There are
five different types of operations masters in Win2K: two that are forest-specific and three that are domain-specific.
Win2K automatically elects the operation master servers during the creation of each Active Directory forest and
domain.

When you use the Active Directory Installation Wizard to create the first domain in a new forest, all five of the
]single master operations roles are automatically assigned to the first domain controller in that domain. In a small
Active Directory 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 two forest-specific operations master roles are listed below:
Schema master
The domain controller that serves the schema master role is responsible for all updates and modifications to
the forest-wide Active Directory schema. The schema defines every type of object and object attribute that
can be stored within the directory. Modifications to a forest’s 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.
Domain naming master
The domain controller elected to the domain naming master role is responsible for making changes to the
forest-wide domain name space of the Active Directory. 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 emulator
If a Win2K domain contains non-AD-enabled clients or is a mixed-mode domain containing Windows NT
backup domain controllers (BDCs), the PDC emulator acts as a Windows NT primary domain controller
(PDC) for these systems. In addition to replicating the Windows NT-compatible portion of directory
updates to all BDCs, the PDC emulator is also responsible for time synchronization on the network (which
is important for Win2K’s Kerberos security mechanism), and processing account lockouts and client pass
word changes.
RID master
The RID (relative ID) master allocates sequences of RIDs to each domain controller in its domain.
Whenever a Win2K 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 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 master
When an object in one domain is referenced by an object in another domain, it represents the reference by
the Globally Unique IDentifier (GUID), the Security IDentifier (SID – for objects that reference security
principals), and the Distinguished Name (DN) of the object being referenced. The infrastructure master is
the domain controller responsible for updating an object's SID and distinguished name 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. Note: 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 global
catalog server. If you use a global catalog 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 where all domain controllers in a domain are also acting as global catalog servers, the infrastructure
master role is unnecessary since all domain controllers will have current data.
Because the operations masters play such critically important roles on a Win2K network, it’s essential for proper
network operation that all the servers hosting these roles are continually available.
Sites
The final, and perhaps most important component of AD’s physical structure is a site. Sites allow administrators to
define the physical topology of a Win2K network, something that wasn’t possible under Windows NT. Sites can be
thought of as areas of fast connectivity (e.g. individual office LANs), but are defined within AD as a collection of
one or more IP subnets. When you look at the structure of the IP protocol, this begins to make sense – different
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. It’s 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 into the network to automatically locate their closest
domain controller and use that controller to authenticate. This helps prevent a situation commonly seen under NT,
wherein logon authentication requests often traverse low-bandwidth WAN connections to remote domain con-
trollers in situations where the local domain controller is temporarily busy and the client computer has erroneously
cached the faraway controller as the default controller to use for logons. In a similar fashion, sites also give other
components within a Win2K network new intelligence. For example, a client computer connecting to a server
running the Distributed File System (Dfs) feature in Win2K can use sites to locate the closest DFS replica server.
It’s important to remember that sites are part of the physical structure of AD and are in no way related to the logical
constructs we’ve already discussed, such as domains and OUs. It’s 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 and Win2K network design planning.
For sites that house multiple domains (e.g. an organization that divides business units into domains rather
than OUs, thus hosting multiple business unit domains on a single site), it’s important to remember to place
at least one, and possibly two, domain controllers for each domain that users will authenticate to from that
site. This outlines the biggest disadvantage of the business unit domain model: the potential for requiring
many domain controllers at each and every site.

AD’s Backbone: DNS
The TCP/IP network protocol plays a far larger role in Win2K than with previous versions of Windows NT.
Although other legacy protocols such as IPX and NetBEUI continue to be supported, most of the internal
mechanics of Win2K networks and Active Directory are based on TCP/IP.
In Win2K, 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 Windows NT-based
networks, NetBIOS is the primary namespace, and WINS the primary name-to-IP address resolution service. With
Win2K, Microsoft has abandoned the use of NetBIOS as the primary network namespace and replaced it with
DNS, which is also used on the Internet.
Like Active Directory, DNS provides a hierarchical namespace. Both systems also make use of 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 host’s name to the domain name within
which the host is located. Multi-part domain names (i.e. domains that are several levels deep in the hierarchy of the
DNS namespace) are listed with most important domain division (e.g. .com, .org, .edu, etc.) at right and the least
important – the host name – at left. In this way, a host system’s 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 a Windows NT network for name-to-IP address
resolution, the use of DNS is optional and mainly of interest to enterprises running in heterogeneous environments
or Internet-based applications. However, DNS plays a far more critical role in the Win2K Active Directory. In
Win2K, DNS replaces NetBIOS as the default name resolution service (however, it is still possible to continue
using a NetBIOS namespace and WINS servers on a Win2K network for legacy systems and applications). In
addition, Win2K domains use a DNS-style naming structure (e.g. a Win2K domain might have a name such as
‘santarosa.realtimepublishers.com’ or ‘mydomain.net’), which means the namespace of Active Directory domains is
directly tied to that of the network’s DNS namespace.
This namespace duplication will normally 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.

Finally, Win2K and Active Directory use DNS as the default locator service; that is, the service used to convert
items such as Active Directory domain, site, and service names to IP addresses.
It’s important to remember that although the DNS and Active Directory namespaces in a Win2K 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 (e.g. host address/A records, server resource/SRV records, mail
exchanger/MX records, etc.) of the DNS zone files for those domains, whereas the Active Directory contains a wide
variety of different objects including domains, organizational units, users, computer, and group policy objects.
Another notable connection between DNS and the Active Directory is that Win2K DNS servers can be configured
to store their DNS domain zone files directly within the Active Directory itself, rather than in external text files.
Although DNS doesn’t rely on the Active Directory for its functionality, the converse is not true: Active Directory
relies on the presence of DNS for its operation.
Win2K includes an implementation of Dynamic DNS (defined by RFC 2136) that allows AD-enabled clients to
locate important Win2K 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 Win2K
network (not to mention the availability of the systems and services they reference).
Introduction to AD and Win2K Monitoring
As you’ve already learned, Win2K introduces a number of new and important infrastructure components that did
not exist in Windows NT networks. As a result, ensuring the health and availability of your Win2K 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 place.
Unfortunately, IT departments in some organizations are purely reactive when it comes to network infra
structure 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 since such information is delivered in an on-demand fashion, it is of diminished
value when compared to real-time monitoring systems. These organizations will be at high risk of down
time and financial loss in a Win2K environment.
Existing monitoring procedures in place using home-grown or built-in tools.
A second category is where the need for proactive network monitoring is recognized, but has been imple
mented by the organization using basic, low-cost tools (e.g. shareware/freeware utilities or those provided
with the OS or the Resource Kit). This includes tools such as Event Viewer and Performance Monitor,
Resource Kit utilities (e.g. NLTEST, BROWMON, NETDOM, DOMMON, DATALOG, REPADMIN,
REPLMON, DFSCHECK, and similar utilities), and freeware/shareware utilities (e.g. 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, etc.) 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 NT/2000, the Resource Kits, and freeware/shareware utilities, these utilities typically include intel
ligent scripting to provide sophisticated testing as well as corrective actions in the event of failure. In addi
tion, 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 Win2K networks, this type of tool is highly recommended.
For administrators of Windows NT (or other operating systems) networks that have existing monitoring tools and
procedures, the migration to Win2K will mainly involve an upgrade of existing tools and staff knowledge about the
vulnerabilities of the new environment. However, if your organization has employed a more reactive stance (i.e. fix
it only when it breaks) with regards to resolving network problems, you’ll quickly find that this methodology can
be especially troublesome in a Win2K environment.
Although it is true that Win2K provides 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. Although legacy
Windows NT networks have their own set of dependencies and vulnerabilities, they are far fewer in number due to
NT’s simpler (and less capable) network architecture. Let’s quickly review the primary monitoring considerations in
a Windows NT environment are as follows:
PDC availability and performance
Due to the single-master nature of NT domains, there is a high dependence (and thus, a high availability
requirement) on the Primary Domain Controller (PDC) of each Windows NT domain. Although Backup
Domain Controllers exist to create fault-tolerance and load-balancing for client logon authentication, a
Windows 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, net
work logon traffic loads on domain controllers should be monitored to assess domain controller perform
ance and the ability to respond to client network logon authentication requests within an acceptable period
of time.
Domain trust relationships
On 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 servers
Another aspect of NT networks requiring continual monitoring is the availability of network name servers.
For the majority of Windows NT-based networks (including those with Windows 95/98/ME/2000 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.

Network browser service
Windows NT, Windows Me, Windows 98, Windows 95, and other members of the Windows product family
rely on a network browsing service to build lists of available network resources (e.g. 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 which requires frequent attention and maintenance.
Other critical services and applications
In 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 metrics
All networks, Windows 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, and disk space resource usage on all
critical servers, as well as network connectivity and bandwidth usage.
AD and Win2K Monitoring Considerations
A functioning Win2K network is a complex mesh of relationships and dependencies involving a variety of different
systems and services, including Active Directory, DNS, the global catalog, and operations master servers. Running
an effective Win2K network means having a handle of every aspect of your network environment at all times.
It’s no surprise that the primary monitoring consideration in Win2K is Active Directory and its related services and
components. This includes responsiveness to DNS and LDAP queries, AD inter-site and intra-site replication, and
a special Win2K service called the Knowledge Consistency Checker (KCC). In addition, the health and availability
of services such as DNS, the global catalog, and DFS are also important.
The Knowledge Consistency Checker (KCC) is a special Win2K service that automatically generates Active
Directory’s 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 isn’t 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 (e.g. via Performance Monitor) related to
Active Directory replication, simply having this information at hand doesn’t 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.

In order to ensure the health and availability of the Active Directory as well as other critical Win2K network services,
organizations will need to regularly monitor a number of different services and components, which are listed in
Table 1.2.
Category
Domain Controllers/Active
Directory
Potential Problems
Low CPU or memory resources on domain controllers
Low disk space on volumes housing the SYSVOL folder, the Active Directory
database (NTDS.DIT) file, and/or the Active Directory transactional log files
Slow or broken connections between domain controllers (within a site or across sites)
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 Active Directory synchronization requests
NetLogon (LSASS) service not functioning properly
Directory Service Agent (DSA) service not functioning properly
Knowledge Consistency Checker (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 downlevel NT domains
Low Active Directory Cache Hit Rate for Name Resolution Queries (e.g. due to
inefficient Active Directory Design)
Replication Failed replication (e.g. 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
Global Catalog Slow or failed global catalog query responses
Global catalog replication failures

Change Monitoring and Auditing
In addition to monitoring and troubleshooting problems within the Win2K network infrastructure, another
distinct advantage of monitoring software is the ability to monitor and audit changes made to the Active Directory
database. In many organizations, there may be dozens or even hundreds of administrators making daily changes to
the Active Directory. In order to manage the potential chaos this situation presents, it’s 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 what –
and when. Examples of the kinds of changes that you might want to track include changes to the Active Directory
schema, OUs, contacts, computers, printers, and directory recovery actions taken by administrators (e.g. a site
administration restoring Active Directory on a local domain controller).
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, e-mail alerts, pager notifications, and SNMP traps.
In addition to providing problem identification and alerting features, many third-party products also provide auto-
matic 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.
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 (PDC emulator,
RID allocation, Infrastructure, Domain Naming, Schema)
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 Active Directory-based Win2K Networks.

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 the service restart fails; a different
machine is promoted to replace that system in the event the computer restart attempt fails, and so on.
Other Considerations
There are several considerations you should keep in mind when creating a Win2K network monitoring and
troubleshooting solution. One is the overall architecture of the application(s) being used in the solution. It’s
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 since they 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 or not they provide a support
knowledgebase of common problems and solutions. This kind of knowledge is invaluable from both a technical
and financial standpoint, since 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 capability by allowing administrators to add their own experience to the knowledgebase or a problem tracking
and resolution database, thereby leveraging internal IT staff expertise and creating a comprehensive problem
resolution system.
A final feature provided by some applications, and one that may be of interest to IT shops engaged in Service Level
Agreements (SLAs), is the ability to generate alerts and reports that address exceptions to, or compliance with SLA
obligations.
Summary
Although Win2K and Active Directory represent a quantum leap forward in the NT product line, they also introduce
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 the Active Directory and other critical
services is an essential part of managing Win2K-based networks. In this chapter, we discussed the most important
features and components of Win2K and Active Directory, their roles within the enterprise, differences between
managing Windows NT 4.0-based networks and Win2K Active Directory-based networks, and some of the basic
metrics and statistics that Win2K network administrators need to watch to help them ensure high availability on
their networks.
In the remaining chapters of this book, we’ll drill down and explore each of the vital areas of Active Directory and
Win2K networks in detail, providing the information, tools, and techniques you’ll need to employ to maintain a
healthy and highly available Win2K network.
eBook Copyright Notice
This site contains materials created, developed, or commissioned by Realtimepublishers.com, Inc. and is protected by
international copyright and trademark laws. No material (including but not limited to the text, images, audio, and/or
video) may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, 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. 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 2

Designing an Effective Active Directory
The main function of Active Directory (AD) is to allow the network resources for Windows 2000 (Win2K) 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. AD can be set up and designed in many different
ways to meet the needs of users and administrators. It’s 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 AD problems in the first place. To do that, you need to start
with a good 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, I’ll give you a solid understanding of how to design an 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 only apply to your site. However, my goal is to give you enough information to ensure
that the design serves the needs of your users and administrators.
Active Directory’s 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 you’ll 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 not
easy, but understanding them and using them correctly are the keys to a good design.
Logical Structures
A list of logical structures used in AD is shown in Table 2.1.
Namespace AD is a namespace because it resolves an object’s 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 users, groups, computers,
printers, servers, and other resources together.
Tree A grouping of domains.
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.
Logical Structure Description
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 to mean the same thing, they’re actually different. To help you understand how
they differ, I’ll 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).
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.
Domain
Contains the object and attribute information for the domain of which the domain controller is a member
Configuration
Contains the rules for creating the objects that define the logical and physical structure of the AD forest
Schema
Contains the rules for creating new objects and attributes.
AD depends on DNS and the DNS-type namespace that names and represents the domains in the forest. It’s
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.

Physical Structures
In addition to the logical structures in AD, several physical structures help you implement the logical structures on
your network. These physical structures are listed in Table 2.2.
Designing Active Directory
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 you 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. 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:
1. Design the forest and trees
2. Design the domains for each tree
3. Design the OUs for each domain
4. Design the sites for the forest and domains.
In the next four sections, I’ll 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 doesn’t form a common
naming context. The trees in a forest share the same directory schema and configuration but don’t need to share the
same namespace. For example, a single directory can contain two companies or organizations. Figure 2.1 illustrates
how two companies named company1.com and company2.com form a single forest.
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 network server that hosts AD in a 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).
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 server Stores the global catalog information for AD.
Physical Structure Description
Table 2.2: The physical structures of AD, which are used to implement the logical directory structures on the network

Figure 2.1: Two companies or organizations named company1.com and company2.com can form a forest in AD.
The forest serves two main purposes. First, it simplifies workstation interaction with AD because it provides a global
catalog where the client can perform all searches. Second, the forest simplifies administering and managing multiple
trees and domains. A forest has the following key characteristics or components:
Global Schema
The directory schema for the forest is a global schema, meaning that it’s 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.
Global Configuration Container
The configuration container exists as a naming context that is replicated to every domain controller in the forest.
Thus, it’s 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 Trust
AD automatically creates bi-directional transitive trust relationships among all domains in a forest. This allows the
security principals, such as users and groups of users, to authenticate from any computer in the forest. However,
this is only true if the users’ access rights have been set up correctly.
Global Catalog
The global catalog contains a copy of every object from every domain in the forest. However, it only stores a select
set of attributes from the objects. By default, the global catalog isn’t placed on every domain controller in the forest;
instead, you determine which domain controllers should hold a copy.

When designing the forest, you need to consider both the users and the administrators. 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 forests. 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.
The answer also depends on which type of organization your company is. If it isn’t 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 company’s information. In addition, each administrative
group wants its independence.
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 probably 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 to multiple forests.
An environment with a single forest is simple to create and maintain. All users view one AD using the global catalog.
Maintaining a single forest is easy because you only need to apply configuration changes 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 global catalog. Thus, all the administrators need to agree on their content and
management. Managing these elements becomes more complicated when you add a forest because it incurs a
management cost. The following is a brief list of the many management issues surrounding multiple forests:
• Each additional forest must contain at least one domain, domain controller, and someone to manage it.
• 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.
• Users wanting access to resources outside their forest need to make explicit queries; this is difficult for the
ordinary user.

• Any synchronization of components among multiple forests has to be done manually or using a
metadirectory service or other synchronization solution.
• Users cannot easily access the network resources contained in other forests.
Setting Up and Managing Multiple Forests
Having to set up and manage two forests might be necessary if two organizations in a company don’t trust one
another or cannot agree on administrative policies. For example, let’s say a company has two locations in different
countries—New 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.
In other situations, 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, it’s difficult to manage user access between two or more forests. The simplest method is
to create explicit one-way trusts among the domains that must trust one another. The one-way trust only allows
access among the domains in the direction that it’s set up. This approach of connecting the forest is shown in
Figure 2.2.
One situation in which you may consider managing multiple forests occurs when two organizations merge or
participate in a joint venture. This puts the administration of your network into the hands of two autonomous
groups. For this reason, multiple trees 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. On the other hand, in short-lived organizations like 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 where 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 you’ll 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.

Figure 2.2: Two forests can allow user access between its domains by establishing explicit one-way trusts.
Only the domains connected by the trusts can allow access between the forests.
Figure 2.3: The namespace of the domain tree shows the hierarchical structure of the tree.

Explicit one-way trusts aren’t transitive. The one-way trusts in Win2K are the same as the one-way trusts that existed
in Windows NT. Creating one-way trusts among multiple forests or trees can be complicated, so it’s important to
keep it simple by limiting the domains that trust one another.
Determining the Number of Trees
A tree is simply a grouping of domains. The domains that form a tree are arranged hierarchical 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 a view of the namespace of the domain trees as shown in Figure 2.3.
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.com can have two
subdomains (or child domains) named seattle.company.com and 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.
However, this isn’t to say that there aren’t 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 namespaces, something that domains don’t 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.
You may 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 only replicated among the domain controllers that are in the domain. Having multiple trees doesn’t
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 includes all domains
that are in separate trees but in the same forest.
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 Windows NT.
A domain can also be called a partition, which is a physical piece of AD that contains the object information.
Figure 2.4 shows a domain structure with its contents of network resources.

The purpose of domains is to logically partition the AD database. Most large implementations of AD need to
divide the database into smaller pieces. Domains enable you to partition AD into smaller, more manageable units
that you can distribute across the network servers.
Domains are the basic building blocks of AD and Windows 2000. Domains can be connected to form the trees
and forests, and what connects them are the trust relationships, which are automatically established in AD. 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.
It’s 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 DNS naming, security policies, administrative rights, and
how replication is 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 for fault tolerance and high network availability
• Determine the explicit trust relationships that need to be established, if any.
Figure 2.4: The domain structure is a piece of AD. It contains the users, groups, computers, printers, servers, and other resources.

Determining the Number of Domains
I recommend that you start with one domain in your environment. This is true even if there are two or more physical
locations. This design keeps the layout of your domain simple and easy to maintain. You can then add other
domains as needed. The mistake some people make is to create a bunch of domains and not know what to do with
them. One domain will be adequate for most companies, especially smaller ones.
Although one domain will work in most circumstances, other circumstances necessitate having more than one
domain for an entire organization. Some of these are described below; you must decide which of these fit your
needs.
Administrative Rights
If your organization has multiple administrative groups that want guaranteed autonomy, you may need to
create additional domains and give each group its individual rights. For example, if two companies merge
together, one group may need to operate and maintain autonomous activities.
International Setting
If your organization is international, you may need to create additional domains to support another
languages. (Administrators, users, and others may need to access AD in their first language, and the schema
contains language-specific attribute display names.)
Replication Traffic
Because the AD database can be distributed, you may 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.
Account Security Settings
Account security settings apply to the entire domain. Account security settings include password length and
expiration period, account lockup 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 may
need to create another domain.
Preserve Existing Windows NT Domain
If your company already has an existing Windows NT domain, you may want to keep it instead of consoli
dating 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 company’s 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.

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.
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.
The first domain you create in an AD forest contains two forest-wide groups that are important to administering
the forest, the Enterprise Administrators group and the Schema Administrators 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, 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 it up 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. This is because 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 it up and restoring it.
Using a Dedicated Root Domain
As I described above, the first domain you create in AD becomes the forest root domain. For smaller implementations
of AD, you may only need to create the root domain, nothing more.
For a larger implementation with multiple locations around the world, however, you’ll 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.
For more information on determining the number of domains, see "Determining the Number of Domains"
earlier in this chapter.

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. 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 don’t carry
administrative privileges while doing regular work.
As I mentioned earlier in "Choosing a Forest Root Domain," 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.
Figure 2.5: A dedicated root domain is small enough to efficiently replicate copies to
the other locations on your network

Assigning a DNS Name to Each Domain
After you’ve 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 I’ve 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 has to 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 Department’s 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.
Using an Internet-Registered Name for the Top-Level Domain
When you name your top-level domain, I recommend that you only use 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
should be registered with the Internet Corporation for Assigned Names and Numbers (ICANN). You don’t 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 doesn’t need to be registered.
Using Internet Standard Characters
When you assign DNS names, you’re 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 (-)
• 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 name) can
not exceed 22 characters (this doesn’t include any extensions)
• Domain names aren’t case sensitive
• Domain names cannot include spaces.
Using Locations to Name Child Domains
When you determine the name of the child domains, I recommend that you use the geographical locations of your
company. This applies to the first layer of child domains that you create under the root domain. The key to designing
and naming this layer is the WAN layout: Try to match the domains to the locations in your company’s WAN. For
example, the first layer of domains that you create under the root could have names based on physical locations.
Figure 2.6 portrays the first layer of domain names, representing the physical, or WAN, locations on your network.
I make this recommendation because other naming schemes based on business structures and organizations are
prone to constant change. In fact, I guarantee that they’ll change and change many times. The AD domain hierarchy
isn’t 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.
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. This includes the physical resources, such as domain controllers, printers, and other equipment supporting
the site.
Figure 2.6: The first layer of domains directly under the root domain is named after the physical, or
WAN, locations on the network.

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 is an easy and efficient
design. However, if your company has multiple physical locations, with network resources spread across them,
you’ll 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.
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, let’s say you decide to use the
domain name engineering.company.com. Don’t 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, known as partitions. By definition, a partition 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 domain
physically stores the containers, objects, and attributes in that branch. Several rules control creating partitions in
AD and how they operate.
• The topmost partition is the root domain
• Partitions don’t overlap (one object cannot be held in two partitions)
• The partitions contain all the information for the naming context.
In AD, the basic unit of partitioning is the domain. So when you create your first partition, you’re actually creating
a child domain under the root domain. The domains in AD act as partitions in the database. This means that each
domain represents a 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.

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, users can still receive whatever
information they request. AD queries the global catalog 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.
Placing the Domain Controllers for Fault Tolerance
After you’ve 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 it’s a global catalog. 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. It’s
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.
Figure 2.7: You can partition the AD database into smaller pieces, then distribute them among net-
work servers or domain controllers.

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, I’ll 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 greatly reduces the overhead of managing trust relationships. The types of trusts that are created are
new in Win2K and 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.
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 they’re automatically established among all domains; this 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 Win2K’s Kerberos security mechanism, are much easier to set up and administer
than Windows NT–style 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’d have to create two-
ways trusts between one domain and every other domain. This would increase the total number of trusts exponen-
tially with the number of domains.
If you have experience with Windows NT domains, you may know something of trust relationships. However, the
trusts in AD differ from NT trusts because they’re transitive. To help you understand what this means, I’ll provide
an example. Win2K transitive trusts work much like a transitive equation in mathematics. A basic mathematical
transitive equation reads as follows:
A=B, B=C, therefore 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, 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.
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 Windows NT, trusts were non-transitive, so they didn’t 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. This means that the trust honors the authentication of the trusted domain. However, having all
administrative rights in a parent domain doesn’t automatically make you an administrator of a child domain.
Policies set in a parent don’t automatically apply to child domains because the trust is in place.

Using One-Way Trusts
One-way trusts aren’t transitive and are used among domains that aren’t part of the same forest. If you’re familiar
with the one-way trusts in Windows NT, the one-way trusts that exist in Win2K are just the same. However,
they’re 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. 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.
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 Windows NT. Because Windows NT domains cannot naturally participate in AD transitive trusts, you
must establish a one-way trust to them. You have to manage one-way trusts manually, so try to limit the number
you use.
In both these situations, you can create two one-way trusts among the domains. However, two one-way trusts don’t
equal a bi-directional transitive trust in AD.
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 only needed 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 doesn’t reside on its own domain, the client first has to
determine where the resource is and locate it. If the resource isn’t 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.
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 up, 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. Let’s 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 like this create a significant amount of network traffic. To alleviate this problem, you can establish a
cross-link between Domain 5 and Domain D. Figure 2.11 illustrates the layout of the domain tree with the cross-link
established between the two domains.
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 is established between domains 5 and D.
The cross-link that has been established serves as an authentication bridge between the two domains. The result is a
better authentication performance between the domains.

Designing Organizational Units 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 you’re designing and creating the hierarchical structure in each domain, it’s important to
understand the following characteristics of OUs:
OUs can be nested
An OU can contain other OUs, enabling you to build a hierarchy inside each domain.
OUs can help delegate administration
You 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 aren’t security principals
You 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 don’t indicate the resources a user can access.
OUs can be associated with a GPO
A 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.
OUs don’t need to be viewed by users
It isn’t necessary for you to design OUs with user navigation in mind. Although users can view the OU
structure, it isn’t an efficient method for finding resources. The preferred method for users to find resources
is by querying the global catalog.
Now that you understand a few of the basic characteristics for OUs, you need to consider the following guidelines
for designing an efficient and effective OU structure:
• Create OUs to delegate administration
• Create OUs to reflect your company’s organization
• Create OUs for Group Policy
• Create OUs to restrict access.
Creating OUs to Delegate Administration
I’ve 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 by creating the following OU:
engineering.chicago.company.com
After you’ve created the new OU and placed all the objects and resources in 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.

Another nice feature that I mentioned earlier (see "Designing Organizational Units for Each Domain") is that OUs
can be nested. This enables you to build a hierarchy in each domain. For example, let’s say 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 you’ve created the new OU and placed the resources, you can give full privileges to the Testing group’s
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 Group Policy objects set, they’re 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 Company’s Organization
If you don’t 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.
Figure 2.12: You can create the Engineering OU in the Chicago domain, then assign permissions
o the Engineering Department administrators to manage all the objects.

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 company’s divisions, departments, and groups. In fact, you can use your
company’s 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.
Creating OUs for Group Policy
Group Policy enables you to define Win2K desktop configurations for users and computers. Desktop configurations
have settings that govern and control the user’s experience at the workstation. 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 a number of items, including installed software, Registry settings, and
logon scripts—just to name a few.
For more information on Group Policy, I recommend that you check out another free eBook from
Realtimepublishers: The Definitive Guide to Windows 2000 Group Policy by Darren Mar-Elia, a link to
which can be found at http://www.realtimepublishers.com.
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 above, 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 aren’t 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 in 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 don’t have the right to read an object, can normally still see it in AD. This may be a problem if you have
highly secure network resources that you don’t 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.
Designing sites and site links in AD takes advantage of the physical network layout. (For an explanation of site
links, see "Creating Sites and Site Links Based on Network Topology" below.) 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 they’re physically close to
the users who depend on them.
It’s your role as an administrator to design the site objects and site links for your tree or forest that assure the best
network performance. It’s 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.
While many subnets can belong to a single site, a single subnet can’t 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 global catalog 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 LAN always 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.
One domain can span more than one site, and one site can contain multiple domains. However, for design
purposes, it’s important to remember that sites define how replication occurs among domain controllers and
which domain controller a user’s 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 together. 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 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.
Cost
Helps the replication process determine the path of the communication among domain controllers
Replication Schedule
Determines what time of day the replication process can execute
Replication Interval
Helps the replication process determine how often to poll the domain controllers on the other side of the link
Transport
Helps 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.
Creating the Site Topology
Sites and site links create the site topology, as shown in Figure 2.15. 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, it’s useful to have a complete set of physical LAN and WAN maps. If your
company has campus networks at one or more locations, you’ll 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. You’ll 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 characters—letters, numbers, and hyphens. (For more information, see "Using
Internet Standard Characters" earlier in this chapter.)
After you’ve created the sites, you need to connect them with site links to truly reflect the physical connectivity of
your network. To do this, you need to first assign each site link a name. Site links are transitive, just like trust
relationships in Win2K. This means that if Site A is connected to Site B and Site B is connected to Site C, it’s
assumed that Site A can communicate with Site C.
The process of generating this site topology is automatic, and it’s handled by a special Win2K service called the
Knowledge Consistency Checker (KCC). If you don’t like the topology that the KCC generates for you, you can
create it 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 you’ve 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 they 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’ll 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 in, communication among them is reliable and fast. Workstations can easily determine the local site at
logon because they already know what TCP/IP subnet they’re 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 global catalog partition. The location of the server is
important because users are required to access a global catalog server when they log on.

Using Sites to Determine the Placement of DNS Servers
I’ve 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 allows all users to access the DNS service locally. You don’t want users to have to
query DNS servers that are offsite to locate the domain controllers that are on their 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. This is the case even if the domain controllers are on the same subnet.
If you depend on an outside DNS service, you may need to adjust the number of DNS servers and physical placement,
if possible. You’ll also need to verify that the outside DNS service supports the required SRV resource record. If it
doesn’t, you may need to install and configure your own implementation of Microsoft’s DNS to support AD.
If you don’t want to depend on an existing DNS service or a DNS service that is offsite, you may 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 was 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 structures
— forests, trees, domains, and OUs. I also recommended that the sites and site links be properly established to
support the distribution and replication of the system. I also discussed the placement of other supporting servers,
such as domain controllers, global catalog 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

Monitoring and Tuning the Windows 2000 System and Network
A Windows 2000 (Win2K) network is a system of devices that work together toward a common goal of providing
communication among users, servers, and applications. The most important of these devices are Win2K domain
controllers. This book is primarily interested in the components or software that are required for Win2K Active
Directory (AD) services. In this chapter, I’ll focus on how you can monitor Win2K domain controllers and their
subsystems to help you reduce downtime and improve AD performance.
Monitoring Windows 2000 Domain Controllers
As previously mentioned, domain controllers are the single most important type of device on an AD-based Win2K
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. Because
domain controllers are crucial to the performance and operation of the directory, it’s 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 down significantly or is unavailable, users
can’t log on, there is no Address Book for Exchange, and users can’t print or access Web-based applications.
When you consider how you’ll monitor your domain controllers, first remember that no one domain controller
contains all of the directory information. In any well-built Win2K 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 isn’t 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 is usually undesirable, especially if there are too many
users and/or if the WAN link is slow.
Another example of why you need to monitor domain controllers is that some domain controllers on a Win2K
network (no matter how many domain controllers it may have) are unique. For example, some Win2K 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 controller, or PDC). This essentially means that these domain controllers don’t have
additional copies or replicas to provide fault tolerance if the domain controller hosting a particular role is down.
As I discussed in Chapter 1, 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 network’s 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
Win2K in the five following areas:
• Overall system
• Memory and cache
• Processor and thread
• Disk
• Network.
I’ll discuss each of these areas, and the reason for their importance, in the following sections. I’ll discuss monitoring
AD itself in Chapter 4.
Monitoring the Overall System
Monitoring a Win2K domain controller means watching the operation of both the server’s operating system (OS)
and its hardware subsystems. When you monitor domain controllers, I recommend that you begin by establishing a
performance and reliability baseline for each—that 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 to the baseline established for that domain controller.
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 controller’s processor is running at 100 percent usage because one
application has tied up the central processing unit (CPU). Almost every NT/Win2K administrator has seen this
occur at some point or another.
Win2K 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. They’re described below.
Task Manager
Gives 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.
Performance console
Allows you to view the current activity on the domain controller and select the performance information
that you want collected and logged. You can customize Win2K’s performance-counter features and architec
ture 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 controller’s performance and estab
lish a baseline for the performance of your domain controllers. Using System Monitor, you can see the per
formance counters graphically logged and set alerts against them. The alerts will appear in Event Viewer.

Performance Logs and Alerts enable you to collect information for those times when you can’t detect a
problem in real time. Performance Logs and Alerts allows you to collect domain controller performance
data for as long as you want—days, weeks, or even months.
Event Viewer
Allows 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 console’s logging feature, make sure you don’t
actually create a problem by filling the computer’s disk with large log files.
First, 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 continu-
ally 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. This 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 into the
Win2K OS. I’ll 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 isn’t intended to be an in-depth
study of all the capabilities of these utilities. Instead, my 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.
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 Win2K’s Task Manager. This utility allows you to see which processes or threads are running on a Win2K
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.

Task Manager supplies three pages of information: Applications, Processes, and Performance. Each of these pages
will help you understand more about a domain controller’s processes and memory. I’ll discuss each of these screens
in greater detail later in this chapter.
Using the Performance Console
In Win2K, 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.
Figure 3.1: Win2K’s Task Manager allows you to view and manage the applications
and processes running on a domain controller and manage their performance.
In Windows NT, the Performance console was known as Performance Monitor, and like most NT administration
utilities, it was a standalone utility rather than an MMC snap-in.
The Performance console helps you accurately pinpoint many of the performance problems or bottlenecks in your
system. It monitors your Win2K 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 sys-
tem. 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. System Monitor is shown in Figure 3.2.
Figure 3.2: The Performance console includes both System Monitor and Performance Logs and Alerts.
When it starts up, System Monitor isn’t monitoring any counters or performance indicators for the system. You
determine which counters System Monitor tracks and displays. To add a counter, click the Plus (+) tool 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, as shown in Figure 3.3, where you can choose
which counters to monitor.

Once you choose the counter that you want to view, System Monitor tracks its 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, you’ll 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.
Figure 3.3: In System Monitor, you can choose which counters you want to
track and monitor on the display.
If you don’t 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).
In later sections of this chapter, I’ll 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.
Event Viewer
As with its NT predecessor, Win2K 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,
Win2K provides Event Viewer, which allows you to view the events that have been logged.
Events Tracked in Event Logs
Win2K 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 death," or BSOD). The error message
is displayed on a solid blue background on a domain controller’s console. A number of stop errors are worthwhile
monitoring because they affect the reliability of a computer. Fortunately, stop errors are recorded in a domain
controller’s Event Log when the computer restarts. To view the stop errors in the Event Log, you need to launch
Event Viewer.

In addition to stop errors, if a Win2K domain controller restarts, these events are also recorded in the system log
section of the Event Log. 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 Log is application crashes. Win2K 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 Log. Again, you can use Event Viewer and the
information in the Event Log to analyze problems with an application.
Types of Event Logs
When you use Event Viewer, the Event Log is separated into three logs, as follows:
Application Log
Contains events logged by applications or programs such as Exchange or Microsoft Internet Information
Server (IIS) that are running on the computer. The developer of an application decides which events to
record.
System Log
Contains 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 Log
Records 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 system administrators.
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 eventvwr, then click OK, or choose
Start>Programs>Administrative Tools>Event Viewer. Event Viewer starts and displays the following screen (see
Figure 3.4).

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. The
types of events are as follows:
Error
Signifies that a severe problem has occurred. This means that data was lost or functionality was lost. For
example, if a service fails to load during startup or stops abruptly, an error is logged.
Warning
Less significant than an error and indicates that a problem could occur in the future. For example, a warn
ing is logged if disk space becomes too low.
Information
Describes important situations that need noting. This event is typically used to notify when an operation is
successful—for example, a disk driver loaded successfully and without errors.
Success audit
Logs 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 success
ful, a success audit event is logged.
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
and system logs.

Failure audit
Is 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 illustrates the dialog box that appears to help you specify the filter characteristics.
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 (shown in Figure 3.6), you can type a file name with the .xls extension, or choose a file type, such as Text
(Comma Delimited) (*.csv).

Monitoring Memory and Cache
One of the most common performance problems with Win2K 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 controller’s 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 controller’s memory, I’ll first briefly introduce the memory
model for Win2K. Memory in Win2K provides a page-based virtual memory management scheme (called Virtual
Memory Manager, or VMM) that allows applications to address 4 gigabytes (GB) of memory. Memory in Win2K
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 life. VMM takes care of whether the memory should be
moved to a new location or swapped to disk completely independently of the application.
Because everything in the system is realized using pages of physical memory, it’s 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 aren’t 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 you’ll carry out is to verify that your domain controller has
enough physical memory. Table 3.1 shows the minimum memory requirements for a Win2K domain controller.
Figure 3.6: The events in Event Viewer can be exported for use with various applications.
This
Minimum Installation
Server running a basic set of services
Server running an expanded set of services
Requires this amount of memory
64 MB
128 MB
512 MB
Table 3.1: Minimum memory requirements for a Win2K domain controller.

These recommendations are minimum physical memory requirements. Your physical memory requirements for
actual production servers will typically be much higher. Because your Win2K 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, you’ll need to add memory to support them. If there
isn’t 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 down 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,
it’s 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 I’ve already introduced: Task Manager and the Performance console.
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 Win2K.

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:
MEM Usage
A bar graph that shows the amount of virtual memory 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 applica
tion code. If this situation arises, you need to increase the amount of memory on the system to improve
performance.
Memory Usage History
A 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 if there is a
problem with virtual memory over a longer period of time.
Physical Memory
Tells you the total amount of RAM in kilobytes (K) 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.
Figure 3.7: The Performance page of Win2K’s Task Manager allows you to view a
domain controller’s memory usage.

Commit Charge
Shows three numbers, which all deal with virtual memory on the domain controller: Total, Limit, and
Peak. The numbers are shown in kilobytes K. Total shows the current amount of virtual memory in use.
(You’ll notice that this number matches the number shown in MEM Usage.) Limit is the maximum possi
ble 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 Memory
Shows 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 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.
Available Memory Counters
To determine if 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 controller’s 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 any-
where 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.

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 isn’t an average. It’s calculated by summing space
on three memory lists.
Free
Memory that is ready or available for use.
Zeroed
Pages of memory filled with zeros to prevent later processes from seeing data used by a previous process.
Standby
Memory 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 where applications or processes consume memory but don’t release it
properly. To determine the culprit, monitor each application or process individually to see if 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.
Figure 3.8: Using the Available Bytes memory counter to monitor or track how much memory is left for
users or applications.

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/sec
Indicates the number of page faults without making a distinction between soft page faults and hard page faults.
Page Reads/sec
Indicates the number of times the disk was read to resolve hard page faults. This counter indicates the
impact of hard page faults.
Pages Input/sec
Indicates the number of pages read from disk to resolve hard page faults. This counter also indicates the
impact of hard page faults.
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, it’s 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, it’s 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.
% Usage
Indicates the current usage value that was last recorded.
% Usage Peak
Indicates the high-water mark for the paging file.
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, it’s fairly certain that your
domain controller will be performing poorly.
By default, Win2K automatically creates a paging file on the system drive during installation. Win2K bases the size
of the paging file on the amount of physical memory present on the domain controller (in most cases, it’s 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. This is because SCSI
handles multiple device contention more efficiently than IDE and tends to use less CPU power in the process.
Also, I don’t recommend that you spread the paging file across multiple logical drive volumes (partitions) located
on the same physical drive. This won’t generally aid paging file performance—and 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 Win2K that
requires you to restart the domain controller before the change takes effect. So, if you decide to change any
settings for the paging file, do it during a scheduled maintenance time when it’s safe to take the domain
controller down and doing so won’t 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 computer’s system cache settings. The system cache is an area in memory dedicated to files and appli-
cations 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 if it’s in memory (system cache). That’s because a page in cache responds more
quickly to user requests. If the requested information isn’t in cache, the OS fulfills the user request by reading the
file page from disk.
If the system cache isn’t 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 described below.
Copy Read Hits %
A counter under the Cache object that tracks the percentage of cache-copy read requests that are satisfied
by the cache. The requests don’t 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 application’s buffer.
Cache Faults/sec
A counter under the Memory object that tracks the number of faults that occur when a page sought in the
system cache isn’t found. The page must be retrieved from elsewhere in memory (a soft fault) or from the
hard drive (a hard fault).
When you’re 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, you’ll have a better sense of the significance of the data
provided by the Copy Reads Hits % counter. For example, if it 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 won’t exactly
mirror each other.

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.
Monitoring Processors and Threads
I find that many people mistakenly believe that monitoring a domain controller is focused primarily on the domain
controller’s physical processor(s), or CPUs. However, the truth is that the processor doesn’t do anything unless there
are processes and threads to run. In Win2K, 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
controller’s 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. Win2K is a multithreaded OS that is capable of running multiple
processor threads simultaneously—even, when they’re present, across multiple CPUs.
Figure 3:10: The Copy Read Hits % and the Cache Faults/sec counters show how the domain
controller’s cache is responding.

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, Win2K allows pri-
orities to be assigned to each process and thread. The kernel of the Win2K OS controls access to the processor
using priority levels.
Using Process Viewer to Monitor Processes and Threads
Every Win2K 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 Win2K CD. Process Viewer is a great 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.
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 it’s been running, the memory allocated
to it, and its priority. You can also view each thread that makes up a selected process. For each thread, you can see
how long it’s 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, then click Memory Details.
Figure 3.12: Memory details for each process are displayed by clicking Memory Details in
Process Viewer’s 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 so—it may be vital to your domain controller’s 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 in this chapter (see "Using Task Manager to View Memory on a Domain Controller"), I described 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 Win2K 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
Win2K and displayed in Task Manager.

This view provides a list of the processes that are running—their names, their process identifiers (PIDs), the per-
centage of CPU processing they’re taking up, the amount of CPU time they’re using, and the amount of memory
they’re using. Notice the System Idle Process, which always seems to be toward the top of the process list. This is a
special process that runs when the domain controller isn’t doing anything else. You can use the System Idle Process
to tell how the CPU isn’t loaded because it’s 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 isn’t heavily loaded, at least at the moment you checked.
Working with the List of Processes
You can sort this list of processes according to one of the column labels mentioned above. For example, if you want
to view the processes in order of the amount of memory used, simply click that column’s 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 shown in Figure 3.14, 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.13: Win2K’s Task Manager allows you to view and manage processes that are
currently running on the system.

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. This will take you to the
associated application’s process on the Process tab. This feature helps you associate applications with their processes.
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.
As you may know, highlighting a process in Task Manager, then clicking End Process, stops that process from
running. This is a useful feature because it allows you to stop processes that don’t provide any other means
of being stopped. However, I recommend that you only use this method as a last resort because the process
stops immediately and doesn’t 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.
Viewing Information about Processes
If you view the list of processes from either Process Viewer or Task Manager and don’t 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.

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, I’ll discuss some of the counters and how you can use them.
% 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 computer’s 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.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.

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, you need to find the process that is using a
high percentage of the processor. If there is no obvious CPU "hog," you may want to consider adding another
processor to the domain controller or reducing that domain controller’s workload. Reducing the workload might
involve stopping services, moving databases, removing directory services, and so on.
Interrupts/sec Counter
The Interrupts/sec counter measures the rate of service requests from the domain controller’s 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 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 card’s
driver or the physical card.
The Interrupts/sec count doesn’t include deferred procedure calls; they’re counted separately. Instead, this counter
tracks the activity of hardware devices that generate interrupts, such as the system clock, mouse, keyboard, disk
drivers, network interface cards, and other peripheral devices. (For example, the system clock interrupts the CPU
every 10 milliseconds.) 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. This means that 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.16: The % Processor Time counter give you the ability to view the amount of time that the proces-
sor is doing real work.

Unfortunately, it’s 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. This will help you know
when a hardware problem occurs. For example, a network interface card installed in the domain controller could
go bad and cause an excessive number of hardware interrupts. By having an established baseline, you can quickly
identify that there is a problem.
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; it’s 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 down. Figure 3.18 illustrates how System Monitor shows
Processor Queue Length.
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.
In System Monitor, you can make changes to the graph display. To do this, 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 of the graph and data. For example, if you want to change the graph scale,
click the Graph tab and change the Vertical Scale parameters. To confirm the change, click Apply, then OK.

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 down, 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 slowing down. 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, so adding memory or RAM could be needed. To determine if you need more RAM,
monitor the paging counters.
Monitoring the Disk
Because the hard drives in the domain controller have moving parts, they’re always the slowest subsystem in the
computer. In fact, the hard drive subsystem will typically be over 100,000 times slower than the memory subsystem.
As a result, the architects of Win2K designed the file-system caching service. Its sole responsibility is to move data
off the hard drives and into the faster memory subsystem. This 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 GB storing millions or
billions of files. In turn, memory is relative small and expensive. Therefore, the architects of Win2K designed the
virtual memory system to store pieces of memory on the hard drive, thereby allowing more room for users and
applications. However, as I discussed earlier (see "Paging File Usage"), you pay a performance price for paging.
Figure 3.18: The Processor Queue Length counter indicates how congested the processor is.

Using the Performance Console to Monitor the Disk Subsystem
Because system performance depends so heavily on the disk subsystem, it’s 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 controller’s 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.
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.
The figure 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 here 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
using two counters under the PhysicalDisk object in System Monitor.
Disk Reads/sec counter
Tracks the rate of read operations on the disk.
Disk Writes/sec counter
Tracks 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. This is because 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, as shown in
Figure 3.20.
Figure 3.20: The Disk Reads/sec and the Disk Writes/sec counters show how the domain controller is
handling the disk requests that come to it.
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;
this means that only 20 percent of read requests are forced to the disk. This is valid unless you have an application
that reads a lot of varying data at the same time—for 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.
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, Win2K doesn’t
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.

% 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 usable 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.
This counter allows you to monitor the performance of the disk drives as they start to fill up. This task is important
because as a disk drive starts to run out of space, each write request becomes tougher to perform and slows down
overall disk performance. The reason for this is that as the drive fills up, 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 up, it
works harder to service requests; this is often called thrashing. I recommend that you always leave at least 10 percent
of the disk free to minimize thrashing.
Monitoring the Network
Each Win2K 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 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 Win2K 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.
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.

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 controller’s network performance.
Specific performance counters allow you to watch the computer’s 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 controller’s network
components. These counters represent all the network traffic sent to and received from the domain controller and
all the network interface cards installed on it.
Bytes Total/sec
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/sec
The number of bytes that the domain controller has sent on the network. It indicates the network traffic
that has been sent.
Bytes Received/sec
The number of bytes that the domain controller has received from the network. It indicates the network
traffic that has been received.
The advantage of the last two counters is that they break out the values for traffic sent and received.
I recommend that once you’ve monitored these counters, you compare the results to your domain controller’s total
network throughput. To do this, I suggest that you 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
you’ve 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, you’ll want
to use the Network Interface object in System Monitor. The counters that display the amount of traffic processed
by each network interface card are Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec. The counters in the
Network Monitor is a complex tool that allows you to monitor all kinds of network traffic and troubleshoot a
variety of network problems. Thus, a detailed explanation of it is beyond the scope of this chapter and book.

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/sec
The number of bytes the network interface card has sent and received from the network each second. This
value measures the rate at which bytes are both sent and received on the network interface card; this
includes all frame and media types. This value also provides an overall indication of how busy the network
adapter is.
Bytes Sent/sec
The rate at which bytes are sent on the network interface. This value breaks down the amount of traffic
being sent.
Bytes Received/sec
The rate at which bytes are received. This value breaks down the amount of traffic being received.
Figure 3.22 illustrates how you can use the Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec counters in
System Monitor to monitor the domain controller’s network adapter.
Figure 3.22: The Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec counters allow you to monitor
the domain controller’s network adapter.

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 Win2K domain
controllers; this in turn means watching over the critical OS components and hardware subsystems. To help you
monitor a domain controller and its subsystems, Win2K provides several utilities, and this chapter discussed the
most important ones: Task Manager, the Performance console, and Event Viewer. Using these utilities, you can
watch server resources and subsystems in real time while they work to support the requests by users, applications,
and other servers.
international copyright and trademark laws. No material (including but not limited to the text, images, audio, and/or video)
may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, 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. 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@real-
timepublishers.com

Chapter 4

Monitoring Active Directory
Troubleshooting Active Directory (AD) and AD-based networks requires that you become familiar with AD constructs
as well as monitoring tools and techniques. Monitoring AD allows you to determine whether problems are occurring in
any part of the directory. However, it’s sometimes difficult to accurately determine the cause of a problem because AD is
distributed across domain controllers and interacts with a number of 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 containing many different components. To ensure the health of the directory
as a system, you must monitor all of these components. You also need to understand AD’s internal processes, such
as replication.
In this chapter, I’ll 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. It’s always a
good idea to have a sound understanding of one’s tools before using them, so I’ll start by introducing the tools in
our monitoring tool set.
Using the Monitoring 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 Win2K utilities and Support Tools/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. It won’t give a comprehensive list of all utilities built into Windows
2000 (Win2K) or available on the market, and it won’t provide extensive documentation on any of these tools.
Rather, it’ll focus on tools that represent, in my opinion, the best of the built-in and third-party tools.
Third-Party Tools
In this section, I’ll discuss NetPro’s DirectoryAnalyzer and NetIQ’s AppManager.
DirectoryAnalyzer from NetPro
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 this 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,
your users. If the problem is critical, its integrated knowledge base contains descriptions and troubleshooting methods
that will help you solve it.
DirectoryAnalyzer monitors the individual structures and components of AD—replication, 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 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 severity—warning 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 sidebar, 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.
You can also send alerts to enterprise management systems using Simple Network Management Protocol (SNMP).
This allows you to integrate DirectoryAnalyzer alerts with management consoles such as HP OpenView and Tivoli.
Alerts can also be recorded in the Event Log of the Win2K system and viewed using the Event Viewer utility. (See
"Event Viewer" later in this chapter.)
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.

AppManager from NetIQ
AppManager from NetIQ Corporation is a suite of management products that manages and monitors the
performance and availability of Win2K. One of these management products allows you to monitor the performance
of AD. For example, AppManager verifies that replication is occurring and up-to-date for the directory by monitoring
the highest Update Sequence Number (USN) value for each domain controller. The USN is discussed in more
detail later in this chapter (see "Monitoring Replication"). In addition, inbound and outbound replication statistics
are tracked, as are failed synchronization requests for the directory.
AppManager also allows you to monitor the number of directory authentications per second and monitor 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. This means that 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 e-mail and pager alerts when an event is detected.
Built-In Tools
In this section, I’ll discuss System Monitor, Event Viewer, and REPADMIN.
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 you’ve installed
AD on a server, several performance counters—for replication activity, DNS, address book, LDAP, authentication,
and the database itself—measure the performance of the directory on that computer.
I discussed how to launch and use System Monitor in Chapter 3, so I won’t repeat that information here. Instead,
I’ll 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, I recommend that you always establish a
baseline or normal operation that you can compare the real-time values against. When adding AD counters to
System Monitor, if you don’t 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.

Event Viewer
To view and analyze the events that have been generated by a Win2K domain controller, you can use the Event
Viewer. This utility allows you to monitor the event logs generated by Win2K. By default, there are three event
logs: the application log, the system log, and the security log. (These three logs were described in the "Event
Viewer" section of Chapter 3.) In addition, after you install AD, three more logs are created.
Directory service log
Contains 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 log
Contains 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 logged—for example, if the service starts but cannot locate initializing data, such as zones or
other startup information stored in the domain controller’s 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.
File Replication service log
Contains events generated by file replication on the domain controller. The File Replication service (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.2 shows the Event Viewer startup screen on a domain controller after you’ve installed AD with DNS.

Replication Diagnostics (REPADMIN)
The Replication Diagnostics tool is simply referred to as REPADMIN. It’s a command-line utility that allows you
to monitor and diagnose the replication process and topology in AD. It also provides a number of 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
shares 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
this isn’t usually beneficial or necessary because it’s generated automatically by the KCC.
You can also view the domain controller’s replication partners, both inbound and outbound, and some of the internal
structures used during replication, such as the metadata and up-to-dateness vectors.
You can install the REPADMIN.EXE utility from the SupportTools folder on the Microsoft Windows 2000 CD.
Running the SETUP program launches the Win2K Support Tools Setup wizard, which installs this tool along with
many other useful support tools to the Program FilesSupport Tools folder. Figure 4.3 shows the interface for
REPADMIN.
Figure 4.2: The Event Viewer startup screen lists additional event logs that have been created for AD.

Monitoring the AD Infrastructure
An important aspect of any AD deployment is always 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:
Figure 4.3: The REPADMIN utility allows you to view the replication process and topology.

Domain controllers
These are critical to the proper operation of AD. If one domain controller isn’t 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, it’s critical to monitor and track the performance of all
domain controllers on the network at all times.
Domain partition
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 partition
Stored on domain controllers throughout the network. Only a few domain controllers store a copy of the GC
partition, and they need to be monitored for the GC. GCs are specialized domain controllers whose
availability is necessary for clients to be able to log on to the network. The GC streamlines directory searches
because it contains all of the objects in the forest but only a few of their key attributes.
Operations masters
These (or FSMO role holders) are single-master domain controllers that perform special roles for AD. It’s
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 topology
Are 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 isn’t 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 hasn’t 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, it’s very difficult and time-consuming to get back. Thus, it’s critical to
constantly monitor the replication process and topology for problems.
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 isn’t functioning properly, the directory and your users will lose performance
and possibly functionality. If multiple domain controllers aren’t functioning properly, the network can become
unusable. For this reason, I recommend that you always check or monitor that the domain controller’s hardware
and subsystems are operating correctly. (For details on how to monitor the hardware components of the domain
controller, refer to Chapter 3.) After you’re confident that the hardware is performing well, you need to monitor
the AD services running on the domain controllers for errors and other problems.

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.4 shows an example of using
DirectoryAnalyzer to view all alerts for each domain controller.
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 processes—for example, the configuration and activity for the domain partitions, GC partitions,
operations master roles, sites, DNS, the replication process, and the replication topology.
Figure 4.4: 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.
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.

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 don’t understand the alert, you can double-click it; the Alert Details dialog box
will appear and provide more description, as shown in Figure 4.5.
Figure 4.5: DirectoryAnalyzer provides more information about an alert in the Alert Details dialog box.
Once you’ve 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.6 shows an example of the information available in the knowledge base.

As you know by now, 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.
Figure 4.6: DirectoryAnalyzer’s in-depth knowledge base helps you find solutions to problems in AD.

If you select a domain controller, 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.7 shows the DC Information pane in
DirectoryAnalyzer.
Figure 4.7: 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.8 illustrates
the DC Summary pane, which uses green, yellow, and red icons to indicate the status of each domain controller in
a domain.

You can also quickly view where the domain controller resides, if it’s a GC, and who manages the computer. If any
of the domain controllers aren’t showing a green (clear) status icon, there is a problem that you need to investigate
and fix.
Using NTDS Performance Counters
NTDS (NT Directory Service) 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 controller’s 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.
Figure 4.8: The DC Summary pane in DirectoryAnalyzer provides a high-level status of all domain controllers in a domain.
DRA Inbound
Bytes Total/sec
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.
Tracks the total
number of bytes
per second received
on the server during
replication with other
domain controllers.
This Counter Does This How to Use It

DRA Inbound
Object Updates
Remaining in Packets
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.
Tracks the number
of object updates
received in the AD
replication update
packet but not applied
to the local domain
controller.
DRA Outbound
Bytes Total/sec
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.
Tracks the number
of bytes that are sent
from the server
during replication
to other domain
controllers.
DRA Pending
Replication
Synchronizations
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 server’s hardware.
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.
DS Threads in Use 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.
Tracks the current
number of threads
that are being used
by the directory
service running on the
domain controller.
Kerberos
Authentications/sec
Indicates how the domain controller is responding to client
requests for authentications. If this counter doesn’t show
activity over time, clients could be having a problem contacting
the domain controller.
Tracks the current
number of authentica-
tions per second for
the domain controller.
LDAP Bind Time 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.
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.

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.9). By default, System Monitor is started
when you choose Start>Administrative Tools>Performance Console.
LDAP Client
Sessions
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 applica-
tions, or there is insufficient hardware (memory or CPU).
Tracks the current
number of LDAP
sessions on the selected
domain controller.
LDAP Searches/sec Indicates how many LDAP search requests the domain
controller is servicing per second. You typically view different
search rates depending on the domain controller’s hardware,
the number of clients connected to the domain controller,
and what sorts of things the clients are doing.
Tracks the number
of LDAP search
operations that were
performed on the
selected domain
controller per second.
LDAP clients connect-
ing to the server
perform the LDAP
search operations.
LDAP Successful
Binds/sec
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.
LDAP binds per
second that occur
successfully.
NTLM
Authentications
Allows you to see whether there are authentications from
Windows 98 and NT clients for this domain controller. If
you’re 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.
Tracks the total
number of Windows
NT LAN Manager
(NTLM) authentica-
tions per second
serviced by the
domain controller.
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.

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, it’s important that you constantly monitor the state
of the domain partition.
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.10).
Figure 4.9: NTDS performance counters allow you to monitor and track load and performance of the AD
implementation on each domain controller.

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 operations master roles and an operations master consistency check. And finally, you
can view all the trust relationships that exist for the domain. Figure 4.11 shows the Naming Context Information
pane in DirectoryAnalyzer.
Figure 4.10: DirectoryAnalyzer allows you to monitor each domain partition for problems.

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.8 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 Win2K server as
<drive>WINNTNTDSNTDS.DIT.
Figure 4.11: The Naming Context Information pane in DirectoryAnalyzer allows you to see detailed information for a domain.
If necessary, you can relocate the NTDS.DIT database on a domain controller using the NTDSUTIL utility.
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 aren’t installed on the domain controllers. (For instructions on installing
them, see "Installing the Counters" below.)
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 Indicates how database requests are performing. The
value for this counter should be at least 90%. If it’s lower
than 90%, the database requests are slow for the domain
controller, and you should consider adding physical
memory to create a larger cache.
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.
This Counter
Cache Page
Faults/sec
Indicates how the database cache is performing. I recommend
that the computer have enough memory to always cache
the entire database. This means that the value of this counter
should be as low as possible. If the value is high, you need
to add more physical memory to the domain controller.
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.
File Operations
Pending
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.
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.
File Operations/sec 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.
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.
Does This How to Use It
Table Open Cache
Hits/sec
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.
database tables opened
per second. The database
tables are opened by the
cached schema
information.
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.

Installing the Counters
By default, database performance counters aren’t 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%System32ESENTPRF.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 don’t already exist:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesESENT
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesESENT
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:Performanceesentprf.dll
4. Change directory to the %SystemRoot%System32 folder (for example, C:WinntSystem32).
5. Load the counter information into the Registry by executing the following statement:
LODCTR.EXE ESENTPERF.INI
Once you’ve installed the database performance counters, you can use them to track and monitor the database on
the domain controller. As mentioned earlier in "Using NTDS Performance Counters," you can view and track each
counter using the System Monitor utility in the Performance Console.
Monitoring the Global Catalog
As I’ve discussed in previous chapters, special servers on Win2K networks store a Global Catalog (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 this by storing all of the objects in the forest and the key attributes for each. It doesn’t 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.

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
user’s 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 it’s performing. It monitors and tracks the
following conditions:
Domain Controller: Global Catalog Load Too High
Indicates that the domain controller that stores the GC partition has too much traffic. This is LDAP traffic
coming from workstations and servers.
Domain Controller: Global Catalog Response Too Slow
Indicates that the domain controller that stores the GC partition isn’t responding in time to queries and
other traffic.
Replica: GC Replication Latency Too High
Indicates 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 Site
Indicates that there aren’t enough GC servers in the site.
Figure 4.12 shows how DirectoryAnalyzer monitors and tracks alerts for the GC.
Figure 4.12: DirectoryAnalyzer allows you to monitor the GC partition that exists on various domain controllers throughout the forest.

Monitoring Operations Masters
To prevent conflicting updates in Win2K, 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, it’s 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, it’s referred to as a Flexible Single Master Operation (FSMO) role.
There are currently five types of operations masters in AD. The directory automatically elects the operations master
servers during the creation of each AD forest and domain. (For more detail on these FSMOs, see Chapter 1.)
Two operations masters manage forest-wide operations, so have forest-specific FSMO roles.
Schema master
Responsible for schema extensions and modifications in the forest
Domain naming master
Adds and removes domains in the forest.
Three operations masters manage domain operations and so have domain-specific FSMO roles.
Infrastructure master
Updates group-to-user references in a domain
RID master
Assigns unique security IDs in a domain
PDC emulator
Provides primary domain controller 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, it’s 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
operations masters. 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. Figure 4.13 shows the
status of operations masters in the Naming Context Information pane.

You can also use the Naming Context Information pane (shown in Figure 4.13 above) to check the consistency of
the operations masters 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 operations master. In Figure 4.14 below, the domain controller COMP-DC-04 has inconsistent
information about the true owner of the PDC operations master 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.
Figure 4.13: DirectoryAnalyzer displays which domain controllers are holding which operations masters for the naming context.

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 FSMOs.
To monitor the availability of the operations masters, you can click Current Alerts in the sidebar on 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 isn’t responding. This 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, and this 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.15 shows how DirectoryAnalyzer monitors and tracks alerts for each operations master.
Figure 4.14: DirectoryAnalyzer allows you to monitor and check consistency for each operations master.

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; this means that
there is no single source (or master) that holds all of the directory information. Using 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,
that 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.
Figure 4.15: DirectoryAnalyzer monitors and tracks the availability of each operations master.

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; this means that 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 one.
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 allows the GC to know what other objects are available in the forest.
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 doesn’t use date or time stamps to determine what 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 it’s associated with the change. To view the USN of
an object, use the following command at a command prompt:
REPADMIN /showmeta <object 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 doesn’t 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.
As I’ve 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 doesn’t 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:
REPADMIN /showvector <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; above this number, the KCC doesn’t scale well.
The KCC uses the following components to manage the replication topology:
Connections
The 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.
Servers
Each 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 ways—automatically by the KCC or manually by an administrator.
Sites
The 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 needed with no concern for speed or cost—within five 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.
Subnets
Subnets assist the KCC to identify groups of computers and domain controllers that are physically close or
on the same network.

Site links
Site 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 servers
The 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. This means that bridgehead servers are the only servers that replicate across
site links, and the rest of the domain controllers are updated within the local sites.
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 Cycle
The 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 Latency
The 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 Topology
The paths among domain controllers used for replication. If the replication topology evaluates that the
topology is transitively closed (meaning that it doesn’t matter on which domain controller an update
occurs), the topology will provide for that update to be replicated to all other domain controllers.
Replication Failures
Occur when a domain controller involved in replication doesn’t respond. Each time there are consecutive
failures from the same domain controller, an alert is issued. Many things can cause failures—for example, a
domain controller may be too busy updating its own directory information from a bulk load.
Replication Partners
Sets 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 doesn’t
respond, an alert is issued.
Replication Conflict
Occurs 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 you’ll 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.16 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.
Figure 4.16: 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.17 below).

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.18 illustrates an Alert History report.
Figure 4.17: The Current Alerts screen in DirectoryAnalyzer allows you to view the most recent alerts for the replication process.

Summary
Before you can accurately troubleshoot AD, you must be able to effectively monitor it for problems. This means
that you must be able to monitor the directory that has been distributed across domain controllers on the network.
You can do this 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.
Figure 4.18: Using DirectoryAnalyzer, you can produce a report of replication-related alerts.

Chapter 5

Troubleshooting Active Directory
Troubleshooting Active Directory (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 it’s
dynamic and complex by nature, but there are techniques and tools available to make the job easier. In this chapter,
you’ll 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 implementation of AD.
Following a Specific Troubleshooting Methodology
When you troubleshoot AD, I recommend that you 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 doesn’t 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 I 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 possibilities—one by one.
Troubleshooting Network Connectivity
You can troubleshoot network connectivity in a number of ways. For example, you can:
• Test that the hardware you’re using has network connectivity
• Test that Internet Protocol (IP) addresses are correct using the IPCONFIG utility
• Test that Transmission Control Protocol/Internet Protocol (TCP/IP) connections are working using the
PING utility
• Perform other troubleshooting tests 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 controller’s hardware
is functioning correctly, including the computer’s 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 isn’t connected.

Figure 5.1 shows that the domain controller has a local area connection problem. Because the domain controller’s
cable isn’t connected to the network, there is a simple solution to the problem: reconnect the cable.
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 IP Configuration utility (IPCONFIG). IPCONFIG allows you to view and modify the
domain controller’s IP configuration details on the command line. It also checks that the default gateway is on the
same subnet as the local computer’s IP address. For Domain Name System (DNS) dynamic updates, you can use
IPCONFIG to register the computer’s entries in the DNS service.
To view a computer’s TCP/IP configuration, type the following command in a Command Prompt window on the
domain controller or workstation:
IPCONFIG /ALL
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.
Figure 5.1: A red X on the Local Area Connection icon indicates that the network cable is disconnected from your domain controller.

Listing 5.1 shows a well-connected LAN. Notice that the IP addresses are displayed with appropriate values.
Figure 5.2: An unsuccessful TCP/IP configuration and network connection, shown using IPCONFIG.
C:> ipconfig /all
Windows 2000 IP Configuration
Host Name .......................... : cx266988-S
Primary DNS Suffix ................ : company.com
Node Type .......................... : Hybrid
IP Routing Enabled .................. : No
WINS Proxy Enabled .................. : No
Search List ........................ : company.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix ..... : company.com
Description ........................ : Netelligent 10/100TX PCI Embedded
UTP Coax Controller
Physical Address ................... : 00-80-5F-A9-C0-74
IP Address ......................... : 10.0.0.10
Subnet Mask ........................ : 255.255.0.0
Default Gateway .................... : 10.0.0.1
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:
IPCONFIG /ALL > <local_drive>:<text_file.txt>
Listing 5.1: A well-connected LAN, shown using IPCONFIG.
There are many advanced features and switches available with IPCONFIG. To view the available switches,
enter:
IPCONFIG /?

If everything looks normal when you run IPCONFIG, go on to test the TCP/IP connection.
Testing the TCP/IP Connection
You can test the TCP/IP connection among connected servers and workstations using the PING utility. PING allows
you to 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.)
PING 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 this, type the following command:
PING <local_TCP/IP_address>
If the PING test for the local address fails, restart the domain controller and check the routing tables 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 you’ve verified that the local address is working properly, use the PING command to check the communication
WNTIPCFG.EXE in the Windows 2000 Resource Kit
If you’re wondering why Windows 2000 (Win2K) doesn’t contain a graphical TCP/IP configuration utility similar
to the WINIPCFG.EXE file provided with Windows 95/98/Me, you’re not alone. A graphical user interface
(GUI)-based TCP/IP configuration utility (WNTIPCFG.EXE) is included in the Windows 2000 Professional and
Windows 2000 Server resource kits, but by default, the ResKit Setup utility doesn’t install it. To install it,
you need to manually extract the WNTIPCFG.EXE file from the NETMGMT.CAB file, included in the Resource
Kit’s main installation folder, onto your hard disk. (A similar situation existed with NT 4.0. The Windows NT
Server Resource Kit included WNTIPCFG.EXE but didn’t install it by default.) What’s more, the Windows
2000 Resource Kit Supplement 1 doesn’t contain the WNTIPCFG.EXE file, so to obtain it, you need the
original Resource Kit.

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:
PING <domain_controller1_address>
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.
Next, ping the IP address of the remote domain controllers on the remote subnet as follows:
PING <remote_domain_contoller1_address>
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. 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
Computing. 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, where 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 clicking 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.
After the test is completed, the results are displayed at the bottom of the dialog box.
Destination
Shows the name of each destination domain controller you selected.
Test
Shows the type of test that was performed. The type of test varies according to the services that have
been assigned to the domain controller.
Time
Shows the amount of time (in milliseconds) it took to perform each test. If a test is performed in
less than 10 milliseconds, it’s displayed as < 10 ms; otherwise, the actual time is displayed.
Result
Shows whether a test was successful. If the test failed, this column displays a brief description of why.
Figure 5.3: Running the Domain Controller Connectivity test to troubleshoot the communication path among domain
controllers in the forest.

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, where 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 clicking 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.
Destination
Shows the name of each destination domain/domain controller you selected.
Test
Shows the type of test that was performed. The type of test varies according to the services that have
been assigned to the domain controller.
Time
Shows the amount of time (in milliseconds) it took to perform each test. If a test is performed in less than
10 milliseconds, it’s displayed as < 10 ms; otherwise, the actual time is displayed.
Result
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.

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, where 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 clicking 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.
Destination
Shows the name of each destination site/domain controller you selected.
Test
Shows the type of test that was performed. The type of test varies according to the services that have been
assigned to the domain controller.
Time
Shows the amount of time (in milliseconds) it took to perform each test. If a test is performed in less than
10 milliseconds, it’s displayed as < 10 ms; otherwise, the actual time is displayed.
Result
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.

Troubleshooting Name Resolution
DNS is the de facto 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 you’ve 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 aren’t being resolved to IP addresses.
Understanding Name Resolution
The first step in identifying and diagnosing AD name-resolution problems is to review how the Win2K-based
computer registers names and locates domain controllers. For example, whenever you start a Win2K domain
controller, it registers 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 and forest. When the 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. It’s possible that a record is updated in AD but
hasn’t replicated to all DNS servers loading the zone. This might cause consistency problems. By default, all DNS
servers that load zones from AD poll the directory at set intervals (every five minutes, but you can change this) to
update the directory’s representation of the zones.
Checking That DNS Records Are Registered
If DNS records aren’t 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.

Using Event Viewer
If DNS records aren’t registered in DNS—for example, if the DNS client has problems dynamically updating DNS
records—errors 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 data—for example,
zones or boot information stored in the Win2K Registry or (in some cases) AD. Figure 5.7 shows how you can
access the DNS Server log in Event Viewer.

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 using the PING utility. For example, you can check the
names using PING as follows:
PING COMPANY.COM
If this command works, the DNS server can be contacted using this basic network test.
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
this using NSLOOKUP, a standard command-line utility provided in most DNS-service implementations, including
Win2K. 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.
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 entering a host name and the output you can receive:

company.com
Server: ns1.company.com
Address: 250.45.87.13
Name: company.com
Address: 250.65.123.65
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 isn’t found in DNS, you
receive the following message:
The computer or DNS domain name does not exist
Checking the Consistency and Properties of the DNS Server
You can check the consistency and view the properties of DNS servers, zones, and RRs using another command-line
utility called DNSCMD. Windows 2000 Server 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
server’s 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 SupportTools folder located on the Windows 2000 CD-ROM.
For help in using the command, enter the following at a command prompt:
DNSCMD /?
When the DNS Server Doesn’t Resolve Names Correctly
Win2K 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 Win2K service. The caching resolver reduces DNS
network traffic and speeds name resolution by providing a local cache for DNS queries.
Listing 5.2: A sample command and output received using NSLOOKUP.

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 isn’t 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:
1. The resolver sends the query to the first server on the preferred adapter’s list of DNS servers and waits
one second for a response.
2. If the resolver doesn’t 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 two seconds for a response.
3. If the resolver doesn’t receive a response from any server within two seconds, it sends the query to all
DNS servers on all adapters that are still under consideration and waits another two seconds for a response.
4. If the resolver still doesn’t receive a response from any server, it sends the query to all DNS servers on all
adapters that are still under consideration and waits four seconds for a response.
5. If it still doesn’t 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 eight seconds for a response.
6. 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 doesn’t receive a response from any server by the end of the
eight seconds, it responds with a time-out. Also, if it doesn’t 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 doesn’t 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.
Using Other Techniques
A typical problem occurs when a DNS server doesn’t resolve names correctly and provides incorrect data for
queries. For example, if an administrator changed the IP address on a domain controller but DNS wasn’t properly
updated, DNS would supply the incorrect IP address to clients.
When working with Windows 2000 Server and DNS entry changes, you may notice that the DNS server has stale
RRs because they haven’t been updated recently. This means that if there have been previous lookups or name-resolution
activity, the DNS server doesn’t 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 using the IPCONFIG command. Entering the following command allows you to
view the current list of DNS entries that the server has cached:
IPCONFIG /displayDNS
Entering the following command allows you to refresh all DHCP leases and re-register DNS names. (Wait five
minutes for the DNS entries in the cache to be reset and updated with the RRs in the server’s database.)
IPCONFIG /registerDNS

You can also use the IPCONFIG command to dump all of the DNS cache entries.
IPCONFIG /flushDNS
It’s 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 doesn’t 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 it’s not authoritative, the cause is usually
a failed recursive query. Recursion is used in most DNS configurations to resolve names that aren’t 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 server’s 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.
Troubleshooting the Domain Controllers
You have a number of options for troubleshooting domain controllers. Before I discuss them, though, it’s important
to review the AD database and its associated files.
Understanding the Active Directory 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 "Jet." 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.DIT
The main database file; it grows as the database fills with objects and attributes. On the other hand, 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>WINNTNTDSNTDS.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. I recommend that you 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.LOG
EDB.LOG is the current log file for AD. When a change is made to the database, it’s written to this file.
When EDB.LOG becomes full of database transactions, it’s 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, you’ll notice the EDB.LOG file
and at least one or more EDBXXXXX.LOG files.
EDB.CHK
Stores the database checkpoint, which identifies the point where the database engine needs to
replay the logs. This file is typically used during recovery and initialization.
RES1.LOG and RES2.LOG
Placeholders 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.
To manage the database, Win2K 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, it’s not actually removed from the AD database. Instead, it’s 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 Win2K 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 the LDAP protocol
• 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 Windows 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 the
DSASTAT utility. DSASTAT detects and examines the differences among a user-defined scope of objects on two
different 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 -FILTER:
"(&(OBJECTCLASS=USER)(!OBJECTCLASS=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 hasn’t 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 OBJECTCLASS = USER
returns both user and computer objects.
DSASTAT also allows you to specify the target domain controllers and additional operational parameters 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.
DSASTAT also 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.
Analyzing the State of the Domain Controllers
The first 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 2000 Server or Advanced Server CD-ROM; by default, it’s installed in program filessupport tools.
DCDIAG is intended to perform a fully automatic analysis with little user intervention. This means that you
usually don’t need to provide too many parameters to it on the command line. DCDIAG doesn’t work when
run against a Win2K workstation or server, and it’s limited to working only with domain controllers.

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 you’re 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 Test
Verifies that DNS names for the domain controller are registered. It also verifies that the domain controller
can be reached using TCP/IP and the domain controller’s IP address. DCDIAG checks the connectivity to
the domain controller using LDAP and checks that communications can occur using an RPC.
Replication Test
Checks 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 Test
Verifies that all domain controllers holding a specific partition are connected by the replication topology.
Directory Partition Head Permissions Test
Checks the security descriptors for proper permissions on the directory partition heads, such as the schema,
domain, and configuration directory partitions.
Locator Functionality Test
Verifies 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 Test
Identifies and ensures the consistency of domain controllers among sites. To do this, 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 aren’t communicating with other
sites on the network.
Trust Verification Test
Checks explicit trust relationships—that 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
Windows 2000 Resource Kit’s NETDOM utility (not described in this chapter).
For more information on the Windows 2000 Resource Kit’s 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.

Diagnose Replication Latencies Test
Analyzes 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 down the process. This
problem typically occurs because a higher-priority task hasn’t relinquished the computer’s processor or
because a large number of replication requests or tasks is pending. New replication tasks are delayed
because the domain controller is overloaded with replication requests.
Replication of Trust Objects Test
Checks 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) Test
Verifies that FRS has started successfully on all domain controllers. If it hasn’t, this test delays the
NETLOGON service from advertising that domain controller.
Critical Services Check Test
Verifies 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 controller’s machine account if it’s been accidentally deleted.
Using NTDSUTIL
The Directory Services Management utility (NTDSUTIL.EXE) is a command-line utility included in Win2K that
you can use to troubleshoot and repair AD. Although Microsoft designed NTDSUTIL to be used interactively via
a command-prompt session (launched simply by typing NTDSUTIL at any command prompt), you can also run
it 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
Flexible Single Master Operations (FSMOs), purge metadata 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.)

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 have to either run NTDSUTIL after having booted the domain controller via
the special ‘Directory Service Restore Mode’ mode Safe Boot option or set the environment variable
SAFEBOOT_OPTION to a value of DSREPAIR under a normal boot of Windows 2000 (e.g. via the command
SET SAFEBOOT_OPTION=DSREPAIR).
To execute the Info command:
1. Choose Start>Programs>Accessories>Command Prompt.
2. In the Command Prompt window, type NTDSUTIL, then press Enter.
3. At the ntdsutil: prompt, enter the word files. The utility responds by displaying a ‘file maintenance’ prompt.
The following commands have been entered and displayed to this point:
C:>SET SAFEBOOT_OPTION=DSREPAIR
C:>NTDSUTIL
ntdsutil: files
file maintenance:
4. At the File Maintenance prompt, enter the word info to display the location and sizes of AD database
files, log files, and other associated files.

Figure 5.9: Using the Info command in NTDSUTIL to display the location and size of AD database files.
Figure 5.9 shows the output of this command on a domain controller.
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 this, you can use NTDSUTIL’s Integrity option to detect any low-level
database corruption of the directory files. The Integrity option checks that the headers for the database itself 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 this:
1. Restart the domain controller. When you’re prompted, press F8 to display the Windows 2000
Advanced Option menu.
2. Select Directory Service Restore Mode and press Enter.
3. Log on using the Administrator account and password that you assigned during the DCPROMO
process.
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 up space for the data files. (See "Moving the Active
Directory Database or Log Files" later in this chapter.)

To run the NTDSUTIL Integrity option:
3. At the ntdsutil: prompt, enter the word files. The utility responds by showing you the File Maintenance
category.
The commands to this point appear in the Command Prompt window as follows:
I:>NTDSUTIL
ntdsutil: files
file maintenance:
4. At the File Maintenance prompt, enter the word integrity 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
you’re 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.
Figure 5.10: Using the Integrity option in NTDSUTIL to examine the AD database on a domain controller.

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 it addresses
the contents (objects and attributes) of the directory database, not just its low-level structures.
When you run the Semantic Checker, it performs the following checks:
Reference Count Check
Counts 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 doesn’t have a GUID or DN.
Deleted Object Check
Ensures 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 Check
Ensures that the DN tag is equal to the ancestor list of the parent. This could also be stated as a check that
the distinguished name of the object minus its RDN is equal to its parent’s DN.
Security Descriptor Check
Ensures that there is a valid descriptor and that the discretionary access control list (DACL) isn’t empty.
Replication Check
Verifies that there is an up-to-dateness vector in the directory partition and checks to see that every object
has metadata.
Like the Integrity option described above, you can run the Semantic Checker option only when the domain
controller is in Directory Service Restore mode. To run in this mode:
1. Restart the domain controller. When you’re prompted, press F8 to display the Windows 2000
Advanced Option menu.
3. Log on using the administrator account and password that you assigned during the DCPROMO process.
To troubleshoot and repair the AD database, you can use the Integrity option only while the domain controller
is in Directory Service Restore mode.

To run the Semantic Checker option:
3. At the ntdsutil: prompt, type semantic database analysis, then press Enter.
4. Type verbose on. This displays the Semantic Checker.
5. 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 fixup.
The commands to this point appear in the Command Prompt window as follows:
I:>NTDSUTIL
ntdsutil: semantic database analysis
semantic checker: verbose on
Verbose mode enabled.
semantic checker: go
Figure 5.11 shows the results of using the NTDSUTIL Semantic Checker.
Figure 5.11: Using the NTDSUTIL Semantic Checker option to check the consistency of the contents of the directory database.
Cleaning Up the Metadata
The NTDSUTIL program allows you to clean up the metadata 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
Settings,CN=<server_name>,CN=Servers,CN=<site_name>,CN=Sites,
CN=Configuration,DC=<domain>...

The attributes of the NTDS Settings object contain values about the domain controller’s 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 isn’t
properly removed when the domain controller is demoted, you can use the NTDSUTIL utility to manually remove
the NTDS Settings object.
To clean up the metadata:
2. At the command prompt, type NTDSUTIL, then press Enter.
3. At the ntdsutil prompt, type metadata cleanup, then press Enter. Based on the options returned to the
screen, you can use additional configuration parameters to ensure that the removal occurs correctly.
4. 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 connections, then press Enter.
5. If the user who is currently logged on to the computer running NTDSUTIL doesn’t have administrative
permissions on the target server, alternate credentials need to be supplied before making the connection.
To supply alternate credentials, type the following command, then press Enter:
set creds <domain_name user_name password>
6. Type connect to server <server_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.
7. When a connection has been established and you’ve provided the right credentials, type quit, then press
Enter, to exit the Connections menu in NTDSUTIL.
8. When the Metadata Cleanup menu is displayed, type select operation target and press Enter.
9. Type list domains, then press Enter. A list of domains in the forest is displayed, each with an associated
number. To select the appropriate domain, type select domain <number>and press Enter (where <number> is
the number associated with the domain of which the domain controller you’re removing is a member).
The domain you select determines whether the server being removed is the last domain controller of
that domain.
10. Type list sites, then press Enter. A list of sites, each with an associated number, is displayed.
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.)

11. Type select site <number> and press Enter (where <number> is the number associated with the site of
which the server you’re removing is a member). You should receive a confirmation, listing the site and
domain you chose.
12. Type list servers in site and press Enter. A list of servers in the site, each with an associated number, is
displayed.
13. Type select server <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 server’s computer account that you want to remove.
14. After you’ve selected the proper domain and server, type quit to exit the current NTDSUTIL sub
menu. When the Metadata Cleanup menu is displayed, type remove selected server 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:
Error 8419 (0x20E3)
The DSA object couldn’t be found
15. Type quit at each menu to quit the NTDSUTIL utility. You should receive confirmation that the
connection disconnected successfully.
Moving the Active Directory 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 errors messages in the Win2K Event Log. The most common of these
errors is described below, along with their associated symptoms and solutions.
• The following error message may occur when you start AD on a domain controller:
Lsass.exe - System Error
Directory Services could not start because of the following error: There is
not enough space on the disk.Error Status: 0xc000007f. Please click OK to
shutdown this system and reboot into Directory Service Restore Mode, check the
event logs for more detailed information.
When this error occurs, the following events are recorded in the Event Log for the directory service
on the domain controller and can be viewed using Event Viewer:
Event ID: 1393
Attempts to update the Directory Service database are failing with error
112.Since Windows will be unable to log on users while this condition persists,
the Netlogon service is being paused. Check to make sure that adequate free
disk space is available on the drives where the directory database and log
files reside.
Event ID: 428
NTDS (272) The database engine is rejecting update operations due to low
free disk space on the log disk.

• The following warning message is recorded in the System Log of the domain controller and can be viewed
using Event Viewer:
Event ID 2013:
The D: disk is nearing Capacity. You may need to delete some files.
If the disk drive runs out of disk space, AD won’t start up. Win2K 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 up space. If all drives are at capacity, you may 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 this:
1. Restart the domain controller. When you’re prompted, press F8 to display the Windows 2000 Advanced
Option menu.
3. Log on using the administrator account and password that you assigned during the DCPROMO process.
To move the directory database file or log files:
1. 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.)
4. At the ntdsutil: prompt, enter the word files. The utility displays the File Maintenance category.
The commands to this point should appear as follows:
I:>NTDSUTIL
ntdsutil: files
file maintenance:
5. At the File Maintenance prompt, enter the word info to display the location of the AD database files, log
files, and other associated files. Note the location of the database and log files.

6. To move the database files to a target disk drive, type the following command at the ntdsutil: prompt:
MOVE DB TO %s (where %s is the target folder on another drive)
7. 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 (where %s is the target folder on another drive)
8. To quit NTDSUTIL, type quit twice to return to the Win2K command prompt, then restart the
domain controller normally.
Repairing the Active Directory 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 database—if a valid backup is available, always use it first to restore the data. The reason
is that repairing the directory database doesn’t 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.
To repair the AD database file:
3. At the ntdsutil: prompt, enter the word files. The utility displays the File Maintenance category.
4. At the File Maintenance prompt, enter the word repair.
The commands to this point should appear as follows:
I:>NTDSUTIL
ntdsutil: files
file maintenance: repair
5. As soon as the repair operation has completed, run the NTDSUTIL Semantic Checker on the database.
(For instructions, see "Cleaning Up the Metadata" earlier in this chapter.)
I highly recommend that you completely back up AD on the domain controller before you execute the Move
command. In addition, I recommend that you back up AD after you move the directory database file and
log files; restoring the directory database will then retain the new file location.

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.

Troubleshooting Secure Channels and Trust Relationships
When a Win2K 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 isn’t 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 Windows 2000 Resource Kit’s NLTEST command-line utility.
ADcheck: A Free AD and Windows 2000 Network Diagnostic Tool
Although Win2K and the Windows 2000 Resource Kit provide some basic tools for performing troubleshooting
tasks, they aren’t especially easy to use. NetIQ Corporation provides an excellent—and free—utility for
performing a host of AD diagnostic and troubleshooting tasks. ADcheck provides five essential categories
of Win2K diagnostics:
1. Test Domain Controller
Checks the availability of the domain controller, validates DNS records (for example, SRV RRs),
and binds to the domain controller to verify AD status
2. List Domain Controllers
Lists each domain controller along with its name, availability, Active Directory Service
Interfaces (ADSI) scripting location, and site location
3. List Operations Masters
Lists FSMO role holders, compares them to an internal best practices list, and recommends
changes when necessary
4. Test Replication
Checks domain replication topology and displays diagnostic information about replication partners
5. Show Domain Controller Status
Provides 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
to an internal best practices guideline and may recommend changes. Given that it’s completely free, this
tool is something that no Win2K network administrator should be without. You can download ADcheck
from http://www.netiq.com/adcheck/download.asp.

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 domain’s 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 domain’s 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, 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 2000 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 domain’s PDC
once again sends out logon requests to all known trusted domain controllers. However, because this mechanism
tracks only those communications that take 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_query:<account_domain>
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_reset:<account_domain>
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, or FSMOs. A number of operations in the directory have single-master opera-
tions—operations 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 Windows 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 master—Forest-wide and one per forest
• Domain Naming master—Forest-wide and one per forest
• Relative ID master—Domain-specific and one for each domain
• Primary Domain Controller emulator—Domain-specific and one for each domain
• Infrastructure master—Domain-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
you’re assured that the domain controller itself is operating properly, you can turn your attention to the operations masters.
When Operations Masters Fail
If a domain controller holding a FSMO (operations role) master fails, major network problems are almost guaranteed to
ensue. A list of the various operations master roles, their functions, and the effects of losing them are listed below:
Schema Master
If the domain controller holding the forest-wide schema master role fails, you or your directory administrators won’t
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 isn’t visible to directory users and doesn’t affect them.
Domain Naming Master
If the domain naming master role holder in a forest fails, you lose the functionality of adding and removing
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 isn’t visible to
directory users and doesn’t affect them.

Relative ID (RID) Master
If the domain controller that stores the relative ID (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 they 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 doesn’t
need to be available when new object accounts are created.
Infrastructure Master
If the domain controller that stores the infrastructure master role fails, a portion of AD won’t 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, it’s important that it doesn’t fail. However, if
it does, it’s not visible to network users. In fact, it’s visible to only directory administrators when they’ve 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 you’ve
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 global catalog server. For more information about FSMO placement rules and best practices,
see Microsoft Product Support Services article Q223346, at http://support.microsoft.com.
PDC Emulator
If the PDC fails or no longer communicates, users who depend on its service are affected. These are down-level
users from Window 95, Windows 98, and Windows NT 4.0 (or earlier). The PDC is responsible for changes to
the SAM database, changing passwords, 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
you’ve 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 Win2K.
Using the DSA and Schema MMC Snap-Ins
To determine the RID, PDC, and Infrastructure FSMO Holders of a selected domain using Win2K’s built-in tools,
follow these steps:
1. Click Start, Run, type dsa.msc, and press Enter or click OK.
2. Right-click the selected Domain Object in the top left pane, and then click Operations Masters.
3. Click the PDC tab to view the server holding the PDC master role.
4. Click the Infrastructure tab to view the server holding the Infrastructure master role.
5. Click the RID Pool tab to view the server holding the RID master role.
Determining the forest Schema Master role holder is a bit trickier, and involves the following:
1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Schema,
click Close, and then click OK.
3. Right-click Active Directory Schema in the top left pane, and 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 choice in Step 2, you’ll have to have
already registered the Schmmgmt.dll file. If it doesn’t appear as an option, follow these steps to register
it: click 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 forest’s Domain Naming Master role holder requires the following steps:
1. Click Start, Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Domains
and Trusts, click Close, and then click OK.
3. In the left pane, click Active Directory Domains and Trusts.
4. 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 the above methods certainly work, they aren’t necessarily the easiest. The following sections describe
some additional methods for determining FSMO role holders on your network.

Using NTDSUTIL
NTDSUTIL is a tool included with Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000
Datacenter Server. This tool is can be used to verify change certain aspects of the Active Directory. The following is
the steps needed to to view the Flexiible Single Master Operation (FSMO) roles on a given Domain Controller.
Ntdsutil.exe is the only tool that shows you all the FSMO role owners. You can view the PDC emulator, RID
master, and infrastructure master role owners in Active Directory Users and Computers. You can view the schema
master role owner in the Active Directory Schema snap-in. You can view the domain naming master role owner in
Active Directory Domains and Trusts.
1. Click Start, click Run, type cmd in the Open box, and then press Enter.
2. Type ntdsutil, and then press Enter.
3. Type domain management, and then press Enter.
4. Type connections, and then press Enter.
5. Type connect to server <server_name>, where <server_name> is the name of the Win2K domain
controller you want to view, and then press Enter.
6. Type quit, and then press Enter.
7. Type select operation target, and then press Enter.
8. Type list roles for connected server, and then press Enter.
Using the Windows 2000 Resource Kit’s Dumpfsmos.cmd
The Win2K Resource 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.exe 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:
Dumpfsmos <server_name>
Using DCDIAG
Another method involves use of the DCDIAG command. On a Windows 2000 Domain Controller, run the
following command: dcdiag /test:knowsofroleholders /v . Note that the use the /v switch here is required. This
operation lists the owners of all FSMO roles in the enterprise known by that domain controller.
Using AD Replication Monitor
A final method to accomplish this is to use the Active Directory Replication Monitor (Replmon.exe) utility. Before
you can use AD Replication Monitor, you’ll need to install it. The AD Replication Monitor utility is part of the
Windows 2000 Support Tools, which are located on the Windows 2000 Server CD-ROM in the SupportTools
folder. Run the Setup.exe file in this folder to install the tools. Once installed, you can start the AD Replication
Monitor utility by choosing StartProgramsSupport ToolsTools, and selecting Active Directory Replication
Monitor. Once the utility is running, follow these steps to determine the operations master role holders for the
forest and domain:

1. Right-click Monitored Servers, and then add one or more servers using the wizard.
2. Right-click the servers, and then click Properties.
3. Click the FSMO Roles tab.
4. The domain controllers that hold the operations master roles are displayed under the "Owner" column.
5. 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 NetPro’s DirectoryAnalyzer (http://www.netpro.com) and NetIQ’s ADCheck
utility (http://www.netiq.com/ADcheck/Download.asp), provide features to determine the domain controllers
acting as FSMO role holders servers.
An example of viewing the schema master using DirectoryAnalyzer is shown in Figure 5.13.
Figure 5.13: Using a third-party utility to determine which domain controller in your forest holds a particular FSMO role.
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, you’ll need to take steps to force the transfer of the role(s) to
another domain controller. You can accomplish 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 a 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 you’ve 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, follow these steps:
1. On the target domain controller (the domain controller that will be taking over the forest- or domain-wide
operation master role), choose Start>Run. In the Open dialog box, type NTDSUTIL, then click OK.
2. If you’re not running NTDSUTIL on the target domain controller, you need to select and connect to it.
At the ntdsutil: prompt, type connections, then press Enter. Type connect to server <server_name>,
where <server_name> is the name of the server you want to use, then press Enter. To supply additional
credentials, type set creds <domain_name user_name_password> and press Enter. At the Server
Connections prompt, type quit, then press Enter again.
3. At the ntdsutil: prompt, enter the word roles.
4. To seize the role on the currently connected domain controller, enter seize <role_type>, 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.)
5. After you seize the roles, type quit, then press Enter, to return to the previous menu in the NTDSUTIL
interface. Repeat this step until you’ve exited the utility.
6. Reboot the domain controller that seized the operations master role to complete the role change operation.
If the current operations master role holder domain controller is online and accessible, or can be
repaired and brought back online, it’s recommended that you transfer the role using NTDSUTIL’s
transfer command rather than the seize command. For more information on seizing and transferring
flexible single master operation roles, see Microsoft Product Support Services articles Q255504 and
Q223787, 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 don’t report operations masters consistently, long-term problems,
such as replication problems, can arise. There are a number of third-party utilities on the market capable of detecting
domain controller inconsistencies. One example of such a utility is NetPro’s DirectoryAnalyzer, which is capable of
inspecting 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, and this will be reported.

Figure 5.14 shows an example of using a third-party utility (NetPro’s 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.
Troubleshooting the Replication Topology
When you troubleshoot replication problems and errors, it’s important to know who the replication partners of a
specific domain controller are and the status of replication with each one.
Viewing the Replication Partners for a Domain Controller
You can view the replication partners for a specific domain controller using two tools, DirectoryAnalyzer and
REPADMIN.
When you use DirectoryAnalyzer to see replication partners, you’re 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 it’s transitively closed. If it isn’t,
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.
Using REPADMIN
You can also use the Replication Administration utility (REPADMIN) 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 metadata.
To use REPADMIN to view the replication partners for a domain controller, enter the command:
REPADMIN /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.
This is necessary to create the replication links. You can use the following command to force contact:
REPADMIN /KCC

During normal operation, the Knowledge Consistency Checker (KCC) generates automatic replication topology
for each directory partition on the domain controllers. You don’t need to manually manage the replication
topology for normal operation.
In addition to tracking replicated changes, many third-party utilities also 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.
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. This 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:
REPADMIN /SHOWMETA CN=CJOHNSON,OU=ENGINEERING,DC=COMPANY,DC=COM
<domain_controller>
In this command, <domain_controller> is the host name of the target domain controller for which you’re tracking
replicated changes for CJOHNSON 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.
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.
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:
REPADMIN /SHOWREPS <destination_server_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:
REPADMIN /SYNC <directory_partition_DN> <destination_server_name>
<source_server_objectGUID>

An example of running this command to initiate replication between DC1 and DC2 of the domain partition called
COMPANY.COM is seen below. The replication is forced from the source domain controller, DC1, to the destination
domain controller, DC2. To perform the replication, use the following command:
REPADMIN /SYNC DC=COMPANY,DC=COM DC1 d2e3ffdd-b98c-11d2-712c-
0000f87a546b
If the command is successful, the REPADMIN utility displays the following message:
REPLICASYNC() FROM SOURCE: d2e3badd-e07a-11d2-b573-0000f87a546b,
TO DEST: DC1 IS SUCCESSFUL.
Optionally, you can use the following switches at the command prompt:
• /FORCE: Overrides the normal replication schedule
• /ASYNC: Starts the replication event without waiting for the normal replication to finish.
You’ll 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 con-
nections haven’t 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
Replication Monitor (REPLMON) utility allows you to do this. 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.
REPLMON provides a view only from the domain controller perspective. Like REPADMIN, you can install it
from the SupportTools folder on the Windows 2000 CD-ROM. REPLMON has two options that you’ll find
helpful when monitoring AD:
Generate Status Report
Generates 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. 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 Topologies
Displays 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 might appear in the Directory
Service log in Event Viewer. Event Viewer lists errors that pertain to replication, such as Knowledge Consistency
Checker (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.

When the KCC generates this error message, it’s in a mode where it doesn’t 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.
This error could also indicate that there isn’t 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 doesn’t 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 sites—for instance, Site1 and Site2—you 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 above to indicate that a correction needs to be made to the configuration.
Troubleshooting 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 you’ve
probably learned from your own experience, most problems don’t 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 network—and when—is an invaluable troubleshooting tool.
Obtaining this type of change-management data for AD has been difficult or impossible. Win2K doesn’t 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 a number of
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 Computing released a new tool, DirectoryInsight. DirectoryInsight is
unique in that it gives administrators a wide array of information about changes to an AD network that occur over
time. This information includes:
• 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
• Object population counts for GPOs, groups, OUs, domains, domain controllers, servers and computers,
sites, and users at any time.

Figure 5.16: NetPro’s DirectoryInsight AD change-management tool.
It’s 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 Information Technology (IT) budget planning.
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 like 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 logins 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. DirectoryInsight consolidates all of the collected data into a
single, centralized database and provides convenient access to it using a Web-based administration tool (an ActiveX
control running in an Internet Explorer browser window.)
A sample DirectoryInsight screen is shown in Figure 5.16.

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.

Chapter 6

Chapter 6: Backing Up and Recovering Windows 2000 and Active Directory
As a systems administrator, you must protect your network against data loss, computer failures, and loss of directo-
ry services. To accomplish this task, you must back up and restore each Windows 2000 (Win2K) server and the
services each computer provides. You also need to back up and recover critical system data such as the Active
Directory (AD) database, the Registry, and other service-specific configuration databases and configuration files.
Microsoft refers to this set of critical data as System State data.
It’s an unfortunate truth that, regardless of what precautions you take or what quality of hardware you’ve pur-
chased, the odds are that someday, somewhere, you’ll experience a system failure. If your organization depends on
its Win2K systems, you need to know how to troubleshoot and repair them when they fail. Although Microsoft
has greatly improved system reliability and recoverability in Win2K, things still can and do go wrong. Fortunately,
Microsoft provides tools to help you maintain and recover your system.
In this chapter, I’ll cover these new recovery and troubleshooting tools, including the Safe mode startup options,
Win2K Setup’s Emergency Repair Process, and the Recovery Console. I’ll also discuss some advanced recovery
tricks and techniques that you can use to assist in maintaining a high level of OS and network availability. I’ll also
mention some third-party tools that complement Win2K’s built-in recovery features.
Building a Fault-Tolerant System that Includes a Backup and Restore Strategy
The first level of defense against system disaster is ensuring that you’ve implemented at least minimal levels of fault
tolerance on your network servers. Fault tolerance is generally defined as the resilience of a particular computer,
subsystem, or component to various kinds of failures.
At the network level, implementing system fault tolerance might involve installing power-backup equipment (such
as an Uninterruptible Power Supply, or UPS, with line conditioning) on critical network devices and creating a
fault-tolerant routing topology using dynamic routing protocols. In the case of network servers, implementing sys-
tem fault tolerance usually involves creating backup or redundant resources for critical subsystems. The array of
fault-tolerant features for any important network system should always include, at least, the following:
•Disk redundancy—Using one or more levels of Redundant Array of Independent Disks (RAID)
technology, in which the disk subsystem can withstand the failure of any one drive. You can implement
RAID either using software, such as Win2K’s built-in RAID features (either RAID 1/disk mirroring or
RAID 5/disk striping with parity), or using a hardware RAID device or disk controller).
•Power redundancy—In the form of a UPS or power-conditioned backup generator capable of keeping the
system up and running if the power fails. Backup power devices should ideally be connected to the server(s)
they protect using hardware and software (for example, serial or network cabling and either Win2K’s UPS
software or the UPS vendor’s software). This software can inform the server, network administrator, and/or
network users about various power events that affect system availability. The software can also automatically
initiate a proper system shutdown after a specified amount of time or when batteries are running low.
•UPS monitoring and management—For example, Win2K includes a UPS monitoring and management util
ity written by American Power Conversion (a leading UPS vendor). In addition, most UPS devices also
include their own customized UPS management software.

•Clustering solutions—Group servers into single logical entities. Windows 2000 Advanced Server and
Windows 2000 Datacenter Server include a clustering service as well as a Transmission Control
Protocol/Internet Protocol (TCP/IP) load-balancing component called the Network Load Balancing
service. In addition, there are many third-party Win2K server-clustering solutions available on the mar
ket.
•Regular system backups—Maintain offline data redundancy for all critical system data. For example,
you should develop and thoroughly test for each of your production servers and domain controllers a
backup and recovery plan that includes the operating system (OS) and directory services.
Here are some goals and objectives for developing an effective backup and recovery strategy. You should adapt
and expand these strategies to your environment and situation.
•Develop backup and restore methods that ensure that you can quickly recover lost data.
•Make sure that you have a backup for each volume that contains the data. In case of total failure, this
strategy allows you to restore the entire volume.
•Create a backup of AD that includes the entire domain on the domain controller. The backup should
include user accounts and security information.
•Use the log created during backup to determine which files were opened by other applications during
the backup. The names of any files that aren’t backed up appear in the log, so you can use the log to
keep track of which files aren’t being backed up and why. In addition, arrange a time to perform a sepa
rate backup of these files during times when the application isn’t running.
•Keep at least three copies of the backup media and rotate them. In addition, keep at least one copy off
site in case of a catastrophic failure.
•Perform a trial restore periodically to verify that your files are being properly backed up. A trial restore
can uncover problems that don’t show up using backup verifications.
•Secure both the storage device and the backup media to prevent an administrator for another server
from restoring stolen data onto your server. Ideally, this should include keeping an offsite copy as well
as on-site copies of backups.
By far the most important step you can take to prepare yourself for a critical disaster is to back up the system
regularly. Every network should have in place a backup process that regularly copies the system data to secondary
or offline storage devices.
The process should back up the user data files and applications that would need to be recovered if they were lost
or damaged as a result of a disk failing or data becoming corrupted. Backups should also include critical system
data such as the AD database, the Registry, and other service-specific configuration databases and configuration
files.
The acronym RAID originally stood for Redundant Array of Inexpensive rather than Independent Disks
because the idea was to use a greater number of cheaper disks rather than a Single Large Expensive Disk
(SLED). However, the definition was changed because many modern RAID systems are built strictly for
redundancy rather than cost savings, and they often use disks that aren’t necessarily inexpensive.
Wherever possible, choose a hardware-based RAID solution over Win2K’s software-based RAID. Most hard-
ware RAID solutions offer better performance (many RAID controllers include on-board cache random
access memory (RAM) and dedicated processors), advanced RAID levels that offer improved flexibility and
performance, better management features, and easier recovery if a primary disk in a mirror set (RAID-1
volume) fails.

When you develop your backup strategy, you need to know how long it takes to back up an active server or domain
controller on the network. To assist with this strategy, remember not to back up the server during peak hours.
Instead, schedule backups during off-peak hours so that the impact of the backup process is minimal.
Another important consideration in any backup routine is the timing of backups in relation to the availability of
the data files being backed up. For example, many backup utilities can’t back up files that are being used (by users
or applications), so it’s important to schedule backups to occur during off-hours, when network usage is at its low-
est and the maximum number of files are available to be backed up.
Backing up data during off-peak hours is also important from a performance standpoint. For example, backing up
a computer’s data taxes the computer’s resources and makes it less accessible. Also, performing a backup from a
remote computer over the system’s primary network connection can significantly reduce network performance.
Using the Windows 2000 Backup and Restore Utility
Win2K includes a graphical user interface (GUI)-based backup and restore utility called Backup. (The file is called
Ntbackup.exe.) You can use this utility to back up an entire Win2K system, including AD and other critical data.
The Win2K backup utility has been integrated to copy the core Windows 2000 Server distributed services, which
include AD, File Replication service (FRS), and Certificate Services. Backup lets you back up and restore these
services by checking the System State check box in the utility. Backup also supports Remote Storage, Removable
Storage, disk-to-disk operations, and other new Win2K services and features. You can back up data to a tape drive,
a logical drive, a removable disk, or an entire library of disks or tapes organized into a media pool and controlled by
a robotic changer.
The backup utility lets you perform the following tasks:
•Back up selected user files and folders located on the domain controller’s hard drive
•Back up the domain controller’s System State, which are the files central to system operation (the Registry,
AD and SYSVOL, the COM+ Class Registration database, and boot files)
•Restore backed-up files and folders to your server’s hard drive
•Schedule regular backups
•Create an Emergency Repair Disk (ERD), which helps you repair system files that become corrupted.
Backup and restore operations can only be performed by backup operators and local administrators. Members of
the Backup Operators group can back up and restore data on the domain controller. (This group is one of the
built-in groups provided by Win2K.) Any domain user can be granted the user rights to back up and restore files
and directories. Members of the Local Administrators group can back up and restore data files, directories, and the
System State of the domain controller.
To start the backup utility, choose Start>Programs>Accessories>System Tools>Backup. Figure 6.1 shows the
Welcome page.
To reduce the risk of losing data, and to improve data security, store backup sets in a safe that is both
heatproof and fireproof. In addition, as part of your backup cycle, regularly rotate one or more full backup
sets to an offsite location. Thus, if all of the equipment at the primary site is destroyed, you can still
recover your data.

The Welcome page provides three main options to assist you in backing up and restoring your data.
•Backup Wizard—Helps you back up your programs and files to help prevent data loss and damage caused
by disk failures, power outages, virus infections, and other potentially damaging events.
•Restore Wizard—Helps you restore your previously backed-up data in the event of a hardware failure, acci
dental erasure, or other data loss or damage.
•Emergency Repair Disk—Helps you create an ERD that you can use to repair and restart Win2K if it’s
damaged. This option doesn’t back up your files or programs, and it’s not a replacement for regularly back
ing up your system.
In addition to these options, the tabs on the Welcome page allow you to bypass the wizards and select backup and
restore options manually.
Using the Backup Wizard
To perform a basic backup of your domain controller, click Backup Wizard and follow the on-screen instructions.
Specifying Default Options
When you run the Backup Wizard and accept the default settings, all of your computer’s data files and System
Figure 6.1: The Welcome page of the Win2K backup utility.
You can also start the backup utility from a command-line interface or prompt. At the command prompt on
the local computer, simply type Ntbackup.

State data are backed up as a set. The Backup Wizard lets you back up the data to a file or tape on the target com-
puter. When you back up the data, you have to designate a file name and location. Backup files typically have the
.bkf extension, but you can use any extension to override the default. You can save a backup file to a hard drive,
floppy disk, or removable or non-removable media.
Figure 6.2 shows the What to Back Up dialog box, where you select what you want to back up.
In the next dialog box, you can select the type of backup media and the location and name of the destination back-
up file. (By default, the file is called Backup.bkf.)
You can use the backup utility to back up and restore data on either file allocation table (FAT) or NT file system
(NTFS) volumes on your system or domain controller. If you back up data from an NTFS 5 (Win2K NTFS) vol-
ume, you should in most cases restore it to an NTFS 5 volume. If you restore the data to a FAT or Windows NT
4.0 or earlier NTFS volume, you’ll lose certain file and folder features, and you’ll lose data as well—for example,
file permissions, Encrypting File System (EFS) settings, disk quota information, mounted drive information, and
remote storage information.
The Completing the Backup Wizard dialog box, shown in Figure 6.3, presents a summary of your current selec-
tions and allows you to specify additional options, if needed. (These are discussed in "Specifying Advanced
Options" below.) Clicking Finish starts the backup, and the Backup Progress dialog box tracks the progress of the
backup. (See Figure 6.4.)
Figure 6.2: The Backup Wizard prompts you to select what you want to back up on the local
computer.

Figure 6.3: The Completing the Backup Wizard dialog box displays a summary of your current
selections and allows you to choose additional backup options.
Figure 6.4: The Backup Progress dialog box tracks the progress
of the backup.

Specifying Advanced Options
Instead of clicking Finish in the Completing the Backup Wizard dialog box, you can click Advanced and customize
the backup. The Type of Backup dialog box appears, where you can select the specific type of backup to perform.
(See Figure 6.5.)
The backup utility allows you to perform the following types of backup:
•Normal—Copies all selected files and marks each one as having been backed up. (This clears the archive
attribute.) Performing a normal backup of all files restores the state of your computer to the time of the
backup using only the one normal backup. If you then create incremental or differential backups, you have
to restore all the incremental backups or the latest differential after restoring the normal backup.
A normal backup creates a backup of the files, folders, and drives selected with the entire System State of
the server or domain controller while it’s online. (See "Maintaining System State Backups" later in this
chapter.) If the server is a domain controller, AD is backed up as part of the System State. When you back
up the System State for the local computer, you cannot choose to back up individual components of the
System State data because of dependencies among them.
•Copy—Allows copies of all selected files but doesn’t mark each one as having been backed up. (This means
that the archive attribute is cleared.) If you want to back up files between normal and incremental backups,
copying is useful because it doesn’t affect these other backup operations.
•Incremental—Allows you to back up only those files that have been created or changed since the last nor
mal or incremental backup. It marks files as having been backed up. If you use a combination of normal
and incremental backups, restoring files and folders requires that you have the last normal backup set as
well as all subsequent incremental backup sets.
Figure 6.5: The Type of Backup dialog box allows you to choose the mode, or type, of backup to
perform and whether to back up the data files that have been migrated to Remote Storage.

•Differential—Allows you to back up files created or changed since the last normal or incremental backup.
It doesn’t mark files as having been backed up. (This means that the archive attribute isn’t cleared.) If you’re
performing a combination of normal and differential backups, restoring files and folders requires that you
have the last normal as well as the last differential backup.
•Daily—Allows you to copy all selected files that have been modified on the day the daily backup is per
formed. The backup files aren’t marked as having been backed up.
You can also perform a combination of backups. For example, backing up your domain controller data using nor-
mal and incremental backups requires the least amount of storage space and is the quickest backup method.
However, recovering files can be time-consuming and difficult because the backup sets can be stored in several dif-
ferent places, disks, and/or tapes. On the other hand, backing up your domain controller’s data using a combina-
tion of normal and differential backups is more time-consuming, especially if your data changes frequently, but it’s
easier to restore the data because the backup set is typically stored on only a few disks or tapes.
After you’ve selected the type of backup and whether to back up data files migrated to Remote Storage, you can use
the How to Back Up dialog box (shown in Figure 6.6) to specify whether you want the backup to be verified.
Verification reads the backed-up data to ensure its integrity. Verification takes extra time but helps ensure that the
backup is successful.
You can also specify whether you want the backup to use hardware compression, if available. Hardware compres-
sion allows the backup to try and reduce the size of the data files and System State being backed up. Backup files
that have been backed up using hardware compression must be restored to hard drives that support compression.
Figure 6.6: The How to Back Up dialog box provides options to verify the backup and support
hardware compression, if available on the local server.

Another dialog box (not shown) allows you to specify whether to append the backed-up data to an existing backup
file or to replace the existing backup file with the new backup data. The next dialog box, the Backup Label dialog
box, allows you to customize the backup and media labels that are stored with the backup file. (See Figure 6.7.) To
make your life easier, the labels include the date and time of the backup.
In the next dialog box, you can decide when to perform the backup. You can choose Now to perform it immediate-
ly or Later to schedule a time (preferably during off-peak hours) to have the backup run. (Scheduled backups are
discussed in "Backing Up Using Manual Selection" below. After you’ve selected all the advanced options, the
Completing the Backup dialog box appears again and summarizes your backup configuration. Click Finish to run
the backup. When it completes, a backup status report is displayed, as shown in Figure 6.8.
Figure 6.7: The Backup Label dialog box allows you to customize the backup and media labels.

Figure 6.8: The backup status report shows the details of the finished backup.
Backing Up Using Manual Selection
As I mentioned earlier, instead of using the Backup Wizard, you can manually select the options you want to be
available during backup. To do this, on the Welcome page of the backup utility, click the Backup tab. In the
Backup dialog box (shown in Figure 6.9), you can select the data files, folders, and drives to be backed up. You can
also select the storage media, file location, and name for the backup data.

Figure 6.9: The Backup dialog box allows you to select the data files, folders, and drives that you want to be backed
up as well as the backup file name, location, and media type.
Here you can perform the following tasks and set up the backup configuration:
•Select the data files, folders, and drives to be backed up—The Backup dialog box provides a tree view of
the local files and folders that you can back up. You can use this tree view the same way you use Windows
Explorer to open devices and select files and folders.
•Select storage media and backup destination—Backups provide two options for selecting storage media:
removable and non-removable storage devices and tape devices. Storage devices can be hard drives, floppy
disks, and Zip and Jaz drives. The tape device option is only available when the local computer has a tape
drive installed.
After you’ve made your selections, click Start Backup. The Backup Job Information dialog box appears (shown in
Figure 6.10). Here you can customize the backup by specifying a name and a label for the backup and whether the
data should be appended to the backup media.
When you’ve selected these options, click Start Backup to start the backup. The backup utility displays the Backup
Progress dialog box (see Figure 6.4), where you can track the backup procedure.
One handy new feature in the Win2K backup utility is its ability to back up to alternative backup media
such as hard disks, Jaz and Zip drives, optical drives, compact disc-recordable/rewritable (CD-R/RW)
drives, and digital video disc-ROM (DVD-ROM) drives. As a rule, if it has a logical drive letter and Win2K
can write files to it, Win2K Backup can use it as a destination backup device.

If you want to schedule the backup to run at a later time (and unattended), click Schedule; the backup utility will
wait and run the backup at the scheduled date and time you specify. To specify additional backup options, click
Advanced to select the backup type, whether to verify the backup, and whether to back up remote media. You can
specify the type of backup (Normal, Copy, Incremental, Differential, or Daily), indicate whether you want a log file
to record the actions, exclude certain file types from the backup, and verify whether the backup was successful. (For
information on the types of backup, see "Specifying Additional Options" above.)
Maintaining System State Backups
Win2K allows you to back up and restore system components known as System State data or System State backups.
The contents of a System State backup depend on the type of Win2K computer and include:
•The Registry
•System boot files (including all system files)
•AD service
•COM+ Class Registration database
•Certificate Services database
•SYSVOL folder
•Cluster service information
Here is a breakdown of System State backup components by OS:
•Windows 2000 Professional—A copy of the system Registry hive files (as with an ERD), the COM+ Class
Registration database, the system boot files, including Ntldr, Ntdetect.com, and other system data, such as
performance-counter configuration files and all files protected by Windows File Protection (WFP).
•Windows 2000 Server—The Registry, COM+ Class Registration database, system boot files, and, if the
server is a certificate server, Certificate Services information.
•Win2K server that is also a domain controller—In addition to the components for Windows 2000 Server,
a copy of the AD database (Ntds.dit), the log and checkpoint files, and the contents of the SYSVOL folder.
•Win2K server that is also running Domain Name System (DNS)—In addition to the components for
Windows 2000 Server, Directory Services (DS)-integrated as well as non-DS-integrated DNS zone informa
tion.
•Windows 2000 Advanced Server acting as cluster members—In addition to the components for Windows
2000 Server, a copy of the quorum recovery log file.
Figure 6.10: The Backup Job Information dialog box allows you to customize
the backup job you’ve created.

To back up System State data, run the Win2K backup utility and click the Backup tab. In the tree list at the left,
click the System State check box. You have the option of selecting only System State data for a backup or including
it as part of a larger backup that includes local disk volumes. Finally, note that the files migrated to near-line stor-
age by Win2K Remote Storage (RS) and those protected by WFP are only included during a backup if you select
Back Up Data That Is in Remote Storage and Automatically Back Up System Protected Files with the System State,
respectively.
When you back up the System State, a copy of the Registry is placed on the local system partition in a folder under
%Systemroot%RepairRegback (such as C:WinntRepairRegback). If the system Registry files are deleted or
damaged, you can use these backup copies of the Registry hive files to repair your system (for example, using the
Recovery Console) without performing a full restore of the System State data using the Win2K backup utility.
To restore the System State on a domain controller, you must first start your computer in Directory Services
Restore mode. This allows you to restore AD and the SYSVOL folder. When you back up or restore the System
State data, you get all the System State data that is relevant to your server or domain controller. You cannot back
up or restore individual components of the data because of dependencies among the components of the System
State. However, you can restore the System State data to an alternate location; if you do, only the Registry files,
SYSVOL folder files, cluster service information, and system boot files are restored.
Using the Restore Wizard
If you want to restore the data files and System State data that you’ve backed up, you can choose Restore Wizard on
the backup utility’s Welcome page. If a hard disk fails, the Restore Wizard allows you to recover the entire system to
an operational system or restore the system from the ground up.
Before using the Restore Wizard, however, I recommend that you collect the information in Table 6.1; you’ll need
it to perform a successful restore.
For This Do This
Disk configuration Using the Disk Management system utility, record the volumes and sizes of the disks
in your system. If a disk should completely fail, you’ll use this information to re-cre-
ate the disk configuration. All disk configurations must be restored before restoring
the System State or data to your computer. If you don’t, the restore process may fail
or the computer may not start after the restore has finished.
Server name Record the server name. You’ll use it to restore a computer of the same name and
avoid changing many different client configuration settings.
Internet Protocol (IP)
addresses
If the computer has a static IP address, record it so you can set it up manually if you
need to. However, in most cases, the IP address should be restored with the Registry.
Domain information Know what domain this computer belongs to and be prepared to set up a new com-
puter account for it. Even if the computer name doesn’t change, you may need to re-
establish a new account.
Local administrative
password
You must know the local computer’s administrative password used when the backup
was created. If you don’t know it, you can’t log on to the computer once it’s restored
to establish a domain account for the computer. If you’re not part of the domain,
you can’t use a domain account; this applies even if you’re domain administrator.
Moreover, the local administrator’s password is also required to restore the System
State on a domain controller.
Table 6.1: Information required to perform a successful restore.

Figure 6.11: The Welcome page for the Restore Wizard.
When you click Next on the Welcome page, the What to Restore dialog box appears, where you can select the spe-
cific data set that you previously backed up (shown in Figure 6.12). The Restore Wizard provides you with a tree
view of the files and folders the data was in when it was backed up. You can navigate the tree to select the files and
folders in the same way that you use Windows Explorer. The label that you selected for the backup identifies the
data set.
Figure 6.11 shows the Welcome page for the Restore Wizard.
I don’t recommend using the restore procedure for copying a system from one computer to another. The
backup of the System State is server-specific.

When you click Next, the Completing the Restore Wizard dialog box appears. Like its equivalent in the Backup
Wizard, this dialog box shows your current selections and allows you to select advanced options, if needed. You
start the restore by clicking Finish. As in the Backup Wizard, a progress dialog box appears, where you can track
the restore.
Specifying Advanced Options
Instead of running the restore, you can click Advanced on the Completing the Restore Wizard to specify advanced
options. In this case, the Where to Restore screen appears, which lets you select one of three destinations for your
restored files. (See Figure 6.13.)
Figure 6.12: The What to Restore dialog box provides a tree view of the data sets that have
been created. You navigate the tree to select the files and folders that you want to restore.

You can restore to:
•Original location—The folder(s) the data was in when it was backed up. This option is useful if you’re
restoring files and folders that have been damaged or lost.
•Alternate location—Retains the structure of the backed-up folders and files. This option is useful if you
know you’ll need some old files, but you don’t want to overwrite or change any of the current files or fold
ers on your disk.
•Single folder—Doesn’t retain the structure of the backed-up folders and files. Only the backed-up files are
placed here. This option is useful if you’re searching for a file and you don’t know its location.
After you select the location for the restored files, the How to Restore dialog box appears, where you select
how you want your files and folders restored. Again, you have three options.
•Don’t replace the file on my computer—Prevents files from being overwritten on your hard disk. This is the
safest method of restoring files.
•Replace the file on the disk only if the file is older—Allows you to make changes to the files since you last
backed up your data. This option ensures that you don’t lose the changes you’ve made to the files.
•Always replace the file on my disk—Replaces all of the files on your hard drive with files in your backup
data set. If you’ve made any changes to the files since you last backed up, your data will be replaced with
the backed-up data.
Once you’ve made your selection, the Advanced Restore Options dialog box allows you to specify whether you
want to restore security, the Removable Storage database, and/or junction point data. (See Figure 6.14.)
Figure 6.13: The Where to Restore dialog box allows you to select the location of restored
files and folders.

The last dialog box in the Restore Wizard provides a summary of the selections that you’ve made and lets you start
the restore process. Like the Backup Wizard, once you start the restore process, a progress dialog box appears,
which provides details during the restore and completion information once it’s done.
Restoring Required Services
If you have to perform a restore, several server services require special attention to make them operational. Table
6.2 lists the services that require additional effort. The sections below the table provide additional information
about restoring each service.
Figure 6.14: The Advanced Restore Options dialog box allows you to restore security and/or
special system files.
When you restore the System State, your recovery plan should take into account the fact that the age of
the backup tape mustn’t exceed the AD tombstone lifetime (the length of time that deleted objects are
maintained in AD before the system permanently removes them). The default for this value is 60 days. If a
tape older than the tombstone is restored, the restore application programming interfaces (APIs) will reject
all of the data as being out of date. Microsoft discusses this issue in Product Support Services article
Q216993, "Backup of the Active Directory Has 60-Day Useful Life." This underscores the importance of
performing regular backups of AD.

This Service Requires This
Windows Internet Naming Service (WINS)
On a TCP/IP network, the Windows Internet Naming Service (WINS) dynamically maps IP addresses to comput-
er names (Net BIOS names). Because of this, WINS lets users access resources by name instead of requiring them
to use IP addresses that are difficult to recognize and remember. WINS servers support clients running NT 4.0 and
earlier versions of Microsoft OSs.
WINS The WINS database is restored to the state it was in at the time of the back-
up. This overrides the current state of the server.
DHCP DHCP leases are restored to their state at the time of the backup. You must
perform several steps to reconcile the state of this database with the current
state of the network.
Remote Storage During a restore operation, the Remote Storage database is recalled from tape
media when you restart the service—but only if the tapes are available.
Certificate Services server After a restore operation, this server may have outstanding certificates that are
now unknown. You can revoke and re-issue these certificates or leave the old
certificates orphaned.
Windows Media
Services server
After a restore operation, you may have to re-install this server because the
database containing setup information may be lost.
Internet Information
Services (IIS) server
If you perform a complete restore, no problems with IIS should arise. If you
perform a partial restore, you must follow the backup/restore procedures spe-
cific to the IIS service.
AD In a network with more than one domain controller, the default restore
method (non-authoritative) is generally the preferred method for restoring a
failed server. Use the authoritative restore process outlined later in this chapter
(see "Authoritative Restores") only if you want to get the system back to the
state at the time the backup was made. (You’d want to do this, for example, if
you erroneously deleted AD objects from the database and it would be diffi-
cult to re-create them. For more information, see "Developing a Backup and
Restore Strategy for Active Directory" later in this chapter.)
SYSVOL If the computer being restored is the only domain controller on the network,
you must select a restore option in the Advanced Restore Options dialog box
in the backup utility. Otherwise, you need to use the default (non-authorita-
tive) restore process.
Table 6.2: How to handle required server services when performing a restore.

When a Win2K server receives a request from a client computer asking for a mapping from a friendly name to an
IP address, WINS responds. When a restore is completed, the WINS database is restored, but it may be out of date
because the information on the network is dynamic. The database updates itself over time and within a day or two
should be consistent. During this time, some name requests may go unanswered or contain incorrect mappings. If
the WINS database is replicated among several WINS servers (the recommended procedure), you should initiate
replication, which synchronizes the database with the up-to-date server. If no other server is available, it’s best to let
the database synchronize on its own.
Dynamic Host Configuration Protocol (DHCP)
Dynamic Host Configuration Protocol (DHCP) is a networking protocol that offers dynamic configuration of IP
addresses for computers. DHCP ensures that address conflicts don’t occur and helps conserve the use of IP address-
es by centrally managing address allocation.
The DHCP server allocates IP addresses and other network-configuration information to DHCP-aware network
clients. Using DHCP is the most common way to distribute IP addresses in a modern network. The restore process
restores the DHCP database. However, it’s restored to the date the backup was performed, and this can result in
duplicate IP addresses being issued. Having duplicate addresses causes those computers to cease all network opera-
tions.
To avoid this, DHCP has a Safe mode of operation. In Safe mode, DHCP broadcasts on the network to verify that
the IP address it’s about to issue isn’t already in use. After a restore, you need to reconcile the database and enter
Safe mode for a period of one-half of the IP lease duration. Because Safe mode significantly reduces network and
server performance, and because being in Safe mode for this period of time is enough to ensure that DHCP func-
tions properly, Microsoft recommends quitting Safe mode as soon as the one-half lease duration is met.
To reconcile the DHCP database, run the DHCP snap-in, then choose Action>Reconcile while the scope is high-
lighted. In the scope properties dialog box, choose Conflict Detection under Advanced and set the number of
attempts to 1.
Remote Storage Service
The Remote Storage service (the Win2K version of Hierarchical Storage Management) frees up disk space by mov-
ing data from the local hard disk to a remote storage device (such as a tape), from which it can be recalled whenev-
er needed. Users still see and access the data without knowing that it’s been archived.
The Remote Storage service cannot recall its database from the Remote Storage tape during the restore operation
unless the Remote Storage tape is in the correct drive—that is, the drive configured to be the Remote Storage
device—or in the robotic library. If any issues with the service exist, the tape will restore by using the database copy
that the service stores on the tape. This is an automatic process that requires no user intervention.
Certificate Server
Certificate Server is the Win2K service that issues X.509 security certificates for a particular Certificate Authority
(CA). It provides customizable services for issuing and managing certificates for the enterprise.
After performing a restore operation, you don’t have to take any special steps for Certificate Server. However, cer-
tificates may exist on the network that were issued before the restore operation. Although Certificate Server is now
unaware of these certificates, they’re valid and will continue to function.

Internet Information Server (IIS)
Internet Information Server (IIS) is a set of software services that supports Web-site creation, configuration, and
management, along with other Internet functions. If you perform a complete system restore, you don’t need to take
additional steps to restore IIS. If you perform a partial restore of a file only, you may need to use the IIS Microsoft
Management Console (MMC) snap-in to restore the IIS database. You’ll find instructions on doing this in the IIS
Help pages.
Active Directory
For a detailed discussion of how to back up and restore AD as a service, see "Developing a Backup and Restore
Strategy for Active Directory" later in this chapter.
SYSVOL
SYSVOL is a replicated data set that contains the policies and scripts that are used by some Windows security sys-
tems. SYSVOL uses Win2K’s FRS for distribution throughout the network. The three restore options for SYSVOL
are identical to the options for FRS: non-authoritative (the default), authoritative, and primary.
Creating an Emergency Repair Disk (ERD)
You can also use the backup utility to create an Emergency Repair Disk (ERD), which contains critical information
about your Win2K system’s settings. An ERD can be a very helpful resource when you attempt to fix an unstartable
server because it contains information that can help Win2K Setup’s Repair mode repair problems with your
Registry, system files (if they’re accidentally erased or become corrupt), your startup environment, and/or the parti-
tion boot sector on your boot volume.
To create an ERD, make sure you have a blank 1.44-megabyte (MB) floppy disk. Then on the Welcome page of
the backup utility, click Emergency Repair Disk to start the ERD Wizard. From there, you have a single option—
whether you also want to update the hard disk–based copy of the Registry files (which are stored in the
%Systemroot%Repair folder). By default, this folder contains versions of the Registry hive files that were created
right after the Win2K setup process was completed. Therefore, if you want to preserve the original set of Registry
files created during Setup but still update the files when the ERD is created, you need to first copy the files in this
folder to another location.
An ERD contains three files:
•Autoexec.nt—A copy of the %Systemroot%System32Autoexec.nt file, which initializes the MS-DOS
Virtual DOS Machine (VDM) environment used to run MS-DOS and 16-bit Windows applications.
•Config.nt—A copy of the %Systemroot%System32Config.nt file, which initializes the MS-DOS VDM
environment used to run MS-DOS and 16-bit Windows applications.
•Setup.log—A log of files installed during Win2K Setup, along with checksum information that can be
used during the Setup Repair process (an option of Win2K Setup) to verify files against their original
source copies on the Win2K installation source (for example, the Windows 2000 CD-ROM). The
Setup.log file has read-only, system, and hidden attribute flags set, so it isn’t normally visible unless you
configure Windows Explorer to show all files.
You need to restore SYSVOL and AD together; however, to clarify the issues involved, this chapter
explains them separately. For a detailed discussion of how to back up and restore AD as a service, see
"Developing a Backup and Restore Strategy for Active Directory" later in this chapter.

Options to Use When Your Server or Domain Controller Won’t Start
In addition to the internal reliability enhancements (such as WFP, driver signing, and the driver verifier) that make
Win2K less prone to crashes than Windows NT, Microsoft has introduced three new system-recovery features that
make repairing an unstartable Win2K system easier. These are described briefly below and in more detail in the fol-
lowing sections. Third-party tools are another option.
•Safe mode booting—The first option to try is Safe mode and related startup options. This option is easy
and understandable to use. A related option is Last Known Good Configuration, which may provide a solu
tion in situations where a recently installed driver or service is causing problems.
•Recovery Console—If Safe mode fails, the next option to try is the Recovery Console. Only advanced or
administrative users should use this option. This method of starting a failed system uses the OS Setup CD-
ROM or ERD floppy disks you created from the Setup CD-ROM.
•Windows 2000 Setup Emergency Repair Process— If the Safe mode and Recovery Console options don’t
work, try rerunning the Setup program from the Windows 2000 CD-ROM. It may (but isn’t guaranteed
to) repair the system and make it startable.
•Third-party recovery tools—There are a number of excellent third-party recovery tools on the market that
you can use to assist you in troubleshooting and recovering unstartable Win2K systems.
Safe Mode
Safe mode is a boot option that lets you disable certain OS features so that you can successfully start the system.
For example, you can remove offending configurations, such as a newly installed driver, which might be causing a
problem.
Safe mode has a number of startup options that allow you to start using varying system configurations. For exam-
ple, the regular Safe mode starts Win2K in a bare-bones environment (set of drivers and services). It doesn’t provide
access to high-resolution video drivers, nor does it provide networking or other optional services.
To access most of these choices, you press F8 on the Windows 2000 Boot Loader menu when you start up. This
selection displays a menu of the following alternative safe-start options:
•Safe Mode—Starts Win2K with the minimal set of drivers and services necessary. These basic files and
drivers support the mouse, keyboard, monitor, mass storage, and other common services.
•Safe Mode with Networking—Similar to Safe mode but adds drivers and services necessary to enable net
working.
•Safe Mode with Command Prompt— Similar to Safe mode but starts Win2K with a Command Prompt
window instead of Windows Explorer.
•Enable VGA Mode—Starts Win2K in VGA mode by using the Vga.sys driver instead of the regular video
driver.
When you create an ERD, information about your current system settings is saved in the
%Systemroot%Repair folder. Don’t delete or change this folder, or you may not be able to repair problems
with your system. There is a bug in the ERD creation utility that prevents the hard disk–based copies of
the Registry files and the ERD floppy disk from being created if the %Systemroot%Repair folder is empty
when you start creating an ERD. Therefore, if this folder is empty (that is, you moved or deleted the files),
you may need to restore them temporarily from copies made on either that system or another system to
create the ERD. Also, don’t try to create an ERD when your system is already having problems; the ERD
cannot fix future problems.

•Last Known Good Configuration—Starts Win2K using a previous version of the system Registry hive. The
Last Known Good Configuration is the most recent session in which a user successfully started up without
any service or driver-initialization failures and logged on to the computer.
•Directory Service Restore Mode—Recovers the AD database. This option is extremely helpful when you
recover AD and is valid only for Win2K domain controllers. If you plan to start a domain controller in Safe
mode and then use the backup utility with removable storage or AD, this is the only option that supports
this. Note that when you start up a domain controller in Safe mode, AD runs, and you need to log in with
domain credentials—for example, as the domain Administrator. When you start up in Directory Service
Restore mode, AD isn’t started, and you log in with local machine credentials.
•Debug Mode—Enables a startup mode in which the system sends debugging information across a serial
cable to another computer running a debugger. (The mode uses COM2 as the debugging port.)
•Enable Boot Logging—Creates an extended log file of success events and failure events to initialize system
components as they load when Win2K starts. (This behavior is the default for all Safe mode boot options
except for the Last Known Good Configuration and Directory Service Restore mode.) The log file is named
ntbtlog.txt and resides in the %Systemroot% folder (for example, C:Winnt).
Depending on the type of problem you’re experiencing with a system, one or more of these options might be
appropriate in a given set of circumstances.
The Recovery Console
If Safe mode doesn’t start your system, try using the Recovery Console. The Recovery Console is a special boot
mode that provides a command-line interface. You can use it to start and stop services, read and write data on a
local drive (including drives formatted with NTFS), copy data to and from a floppy disk or CD-ROM, format
drives, fix the boot sector or master boot record, and perform other administrative tasks—all outside the Win2K
environment.
The Recovery Console is particularly useful if you need to repair your system by copying a file from a floppy disk
or CD-ROM to your hard drive, or if you need to reconfigure a service that is preventing your computer from
starting properly. For example, you can use the Recovery Console to replace an overwritten or corrupted driver file
with a good copy from a floppy disk.
Using the Recovery Console
To use the Recovery Console:
1. Insert the Windows 2000 Setup CD-ROM into the CD-ROM drive.
2. When the text-based part of the Setup begins, follow the prompts. Choose the REPAIR option
by typing R.
3. When you’re prompted, choose the Recovery Console by typing C.
4. If you have a system that has more than one OS installed, choose the Win2K installation that you need
to access.
5. When you’re prompted, type the administrator password.
6. At the system prompt, type Recovery Console commands, then type either Help for a list of commands
or Help <command name> for help on a specific command.
7. Quit the Recovery Console and restart the computer by typing Exit.
The Recovery Console is extremely powerful, so I recommend it only for advanced users and administrators.

Adding the Recovery Console to the Startup Options
If you want to be able to start Win2K using the Recovery Console, you can add it as an option to the Boot Loader
menu on a functioning computer. To do this:
1. With Win2K running, insert the Windows 2000 CD-ROM into the CD-ROM drive.
2. Choose File>Run.
3. In the Open dialog box, type: D:I386Winnt32 /Cmdcons (where D: is the drive letter assigned to your
CD-ROM drive)
4. Follow the on-screen instructions to complete the installation.
The commands for the Recovery Console allow you to accomplish simple operations such as change to a different
directory or view a directory, and more powerful operations such as fixing the boot sector on the hard drive. You
can display help for the commands by simply typing Help at the Recovery Console command prompt.
Windows 2000 Setup Emergency Repair Process
Another system-recovery option is using the Win2K Setup emergency repair process (or Repair) option. This mode
of Setup, like its Windows NT predecessor, allows you to perform some basic system-repair operations.
Assuming you have an ERD for the non-booting system (for more information on this, see "Creating an
Emergency Repair Disk" earlier in this chapter), make sure you have it ready during this procedure. (Even if you
don’t have an ERD, it may still be possible to use Setup Repair mode to recover the system; see the sidebar below,
"Using Windows 2000 Setup Repair without an ERD.")
The following steps provide a general overview of how to use the emergency repair process from the Setup CD-
ROM:
1. Start your computer from the Windows 2000 Setup disks or CD-ROM—You can only start your computer
from the CD-ROM if your computer hardware and basic input/output system (BIOS) have been set up to
support this option.
2. Choose the repair option during setup—After your computer starts up, the Setup program starts, and
you’re asked whether you want to continue installing the Win2K OS. Press Enter to continue. The installa
tion process starts and allows you to repair your system. During installation, you can choose whether to
install a fresh version of Windows 2000 Server or repair an existing installation of Win2K. To repair a dam
aged or corrupt system, type R. You’re then asked whether you want to repair your system using the
Recovery Console or the emergency repair process. Type R to use the emergency repair process.
3. Choose the type of repair—You can choose either the Fast Repair option (type F) or the Manual Repair
option (type M). The Manual Repair option requires that you make all the repair selections and determine
whether you want to repair system files, the partition boot sector, or startup environment problems. I rec
ommend that only advanced users and administrators use the Manual Repair option and that you use it
only to repair one item at a time when you know the others are intact. For example, if you’re confident that
the partition boot sector and startup environment are both intact, attempt to repair only the system boot
files. (The Manual Repair option doesn’t let you try to repair problems with the Registry. To manually
repair individual Registry settings and files or replace the entire Registry, use the Recovery Console.
However, administrators should be the only ones who use it.)
For a more extensive discussion of the capabilities, commands, and use of the Recovery Console, check
out Chapter 12 of the free eBook The Definitive Guide to Windows 2000 Administration by Sean Daily and
Darren Mar-Elia. You’ll find a link to it at www.realtimepublishers.com.

The Fast Repair option uses a backup copy of the Registry that was created when Setup was first run or
installed on your system. If you choose this option, you may lose settings or preferences you’ve created since
the system was first installed unless you’ve created a System State backup. In this case, the system is restored
to that state.
4. Start the repair process—If you have the required ERD (on a 1.44-MB floppy disk), which you created
using the backup utility, and the original Windows 2000 Server CD-ROM, you can start the repair process.
If you don’t have an ERD, the emergency repair process can attempt to locate your Win2K installation and
start repairing as best it can, but it may not be able to fix everything. If you don’t have the ERD and the
emergency repair process can’t fix your system, you can try to use the Recovery Console or try to re-install
Win2K.
5. Restart your computer—If the emergency repair process was successful, your computer should automati
cally restart, and the repair procedure is complete.
Developing a Backup and Restore Strategy for Active Directory
As the heart and soul of a Win2K network, AD is an essential component that must be available to applications
and users at all times. Because it’s a replicated database, AD is vulnerable to the same kinds of problems that can
plague any database. These problems include, but aren’t limited to:
•A corrupted or invalid database schema (which defines the structure of the database—what type of data it
contains and how the data is arranged)
•Missing DNS records
•Damaged or corrupted information
•Accidental misconfiguration by an administrator.
In case one of these events occurs, it’s imperative that your disaster-preparation routine and disaster-recovery plan
include provisions for backing up and restoring AD.
Using Windows 2000 Setup Repair without an ERD
If you haven’t prepared an ERD, you can attempt to repair a downed server by rerunning the Setup program
from the Windows 2000 Server CD-ROM. Assuming that it can locate the Win2K installation folder (improving
the ability to locate the Win2K installation is one of the primary benefits of having an ERD), Setup might be
able to repair the system using information saved at the time that you originally ran it to install the server. This
information is saved in the %Systemroot%Repair folder on the system partition. If this information is physically
accessible and intact, Setup can use it during the repair process. However, some system settings may be lost
under these circumstances; for more information about this, refer to the Win2K documentation.
Winternals Software Recovery Tools
If you need more help than even Windows 2000’s Setup Repair mode and the Recovery Console can
offer, you may find a savior in the tools available from Winternals Software. Winternals makes a number
of top-notch tools (including ERD Commander 2000, Disk Commander, NTRecover, and NTFSDOS)
designed to help you recover Windows NT and 2000 systems, including even those that are totally
unstartable because of corruption or misconfiguration. Winternals even makes one tool (Remote Recover)
that makes it possible to perform over-the-network recoveries on computers that you aren’t physically
present with. You can find a listing and description of these tools at www.winternals.com.

Backing Up Active Directory
Because the files that make up AD (including Ntds.dit, the primary database file) are continually in use on Win2K
domain controllers, you can’t simply copy the AD database as you might a standard user data file. However, as dis-
cussed earlier in this chapter (see "Maintaining System State Backups"), the Win2K backup utility provides a fea-
ture for performing an online backup of AD. AD is backed up whenever you include System State data as part of a
backup on a Win2K domain controller.
When you back up System State data on a domain controller, you’re backing up all AD data that exists on the serv-
er (along with other system components such as the SYSVOL folder and the Registry). You cannot choose to back
up or restore individual components of the System State data or of AD; it’s an all-or-nothing process. This is
because of the dependencies among the components of the System State.
Although the Win2K backup utility can certainly do the job of backing up AD, most information technology (IT)
shops prefer to use more robust third-party applications for their backup solutions. If your organization is using a
third-party backup application, you need to make sure that you’ve purchased a Win2K-compatible version of the
product. It must be capable of backing up AD or provide a separate agent component that can do so. Windows
NT 4.0–era versions of backup utilities are incapable of understanding AD’s format or backing it up, so for most
companies, migrating to Win2K necessarily means upgrading their backup software.
Restoring Active Directory
Although the process of physically restoring the AD database on a Win2K domain controller from a backup isn’t
logistically complex, there are some important logical and architectural issues you need to take into consideration
before performing any type of AD restore operation. On networks with more than one Win2K domain controller,
remember that AD is automatically replicated and updated among domain controllers and thus doesn’t exist in only
a single location. This has implications for restoring AD. For example, you need to ask questions such as:
Third-Party Windows 2000 Backup Utilities
There are several excellent third-party Win2K backup utilities that are 100% compatible with backing up
and restoring AD. The leaders in the Win2K backup arena include:
- Backup Exec from Veritas (www.veritas.com)
- ARCserveIT from Computer Associates (www.cai.com)
- UltraBAC for Windows NT/2000 from UltraBac Software (www.ultrabac.com)
- ERDisk for Active Directory from Aelita Software (www.aelita.com)
You can back up AD in its entirety only using a full backup; you can’t back up AD incrementally (that is, by
backing up only object data that has changed since the last backup)..
As discussed in "Specifying Advanced Options" earlier in this chapter, the useful life of a backup of AD is
usually only 60 days, so you may experience problems if you attempt to restore AD backup images older
than this into a replicated Win2K network. The reason for the 60-day figure is that the useful life of a back-
up is identical to the tombstone lifetime setting for the enterprise, and in Win2K, the default value for the
tombstone lifetime entry is 60 days. However, you can change this value using the Directory Service (NTDS)
config object. The value is the "tombstoneLifetime" attribute of the CN=Directory Service, CN=Windows NT,
CN=Services, CN=Configuration, DC=COMPANY, DC=COM (for a domain called "company.com"). You can set
the value using the LDP or ADSI Edit utility..

•Is just the local domain controller’s copy of AD corrupted or damaged, or are other replicas on other
domain controllers also in the same state?
•Is the data being restored the definitive copy that should be used to overwrite all other copies of AD object
data? If so, are there changes or structural modifications that might be lost by restoring this copy of AD as
a "master" copy?
•Do you need to restore AD on a local domain controller only to regain functionality on that domain con
troller (for example, is the problem isolated to the local copy of AD on that computer), and should it then
receive updates from other domain controllers using AD replication to bring its data store up to date?
The answers to these questions will help you determine which of the three AD restore modes to choose: non-
authoritative, authoritative, or primary.
•Non-Authoritative Restore—A normal restore; most restore operations are run using this restore mode. You
usually perform a non-authoritative restore when the problem is limited to the local Win2K domain con
troller and the AD replicas housed on other Win2K domain controllers are believed to contain valid repli
cas. During a non-authoritative restore, any data that you restore (including AD objects) retains its original
update sequence number (USN). (AD uses the USN to detect and propagate any changes to the other
domain controllers.) In turn, AD replication uses the USN to detect and propagate any changes to the
other domain controllers in the same domain.
•Authoritative Restore—Used when the other Win2K domain controllers contain invalid replicas or unde
sirable data. In this case, you manually designate the copy of the AD database that you restore. You desig
nate only the local domain controller to be authoritative (that is, the "master" copy from which all other
domain controllers seed their own AD replicas). An authoritative restore modifies the USN of each AD
object that is being restored to the domain controller. This allows the USN of each object to be higher than
any of those that are currently on the domain controller. After all of the objects have been restored, they’re
replicated to the other replicas.
You can use backup data from one domain controller to restore only to the same domain controller. You
cannot use the backup of one domain controller to restore another computer. However, if the domain con-
troller’s system fails and never comes back, you can restore the backup data to another computer that will
take the place of the original domain controller. In addition, to completely back up your environment, you
need to have a backup of every domain controller on the network. Keep this in mind when developing your
backup strategy. Also, because of the importance to the entire system of the domain controller that was
created first in the root domain, you need to frequently back it up.
If you’re using Win2K’s backup utility (Ntbackup.exe) to perform a restore, be aware of the following addi-
tional conditions, which must be met for the System State (including AD) to be successfully restored. If any
of these conditions isn’t met, the restore will fail.
- The server name must be identical to the backed-up server name.
- The drive on which the %Systemroot% folder is located must be the same as when it was backed up.
- The %Systemroot% folder must be the same folder as when it was backed up.
- If SYSVOL or other AD databases are located on another volume, the databases must exist and be on the
same drive as when they were backed up.

Non-authoritative Restores
If the AD replicas on domain controllers other than the one you’re performing the restore on are intact and valid,
you’ll probably want to perform a non-authoritative restore. A non-authoritative restore is a normal, or typical,
restore of the AD objects to the domain controller that originally contained them.
You restore AD by starting the Win2K domain controller in Directory Services Restore mode (discussed in "Safe
Mode" earlier in this chapter). When the system starts up, press F8 at the Windows 2000 Boot Loader menu, then
select Directory Services Restore Mode from the alternate boot menu. Win2K starts in a safe mode, and you can
follow these steps to restore AD information on a domain controller:
1. Log on as a member of the Administrators or Backup Operators groups. I should also point out that the
members are local computer users and groups, not domain users and groups. Also, users who are backup
administrators (but not regular administrators) can’t run Ntdsutil to do things like authoritative restores.
This requires a user with administrative privileges.
2. Run the Win2K backup program. On the Welcome page, click Restore Wizard, then select the System
State check box.
If you restore the System State data and you don’t designate an alternate location for the restored data, the
backup utility erases the System State data that is currently on your computer and replaces it with the
System State data you’re restoring. If you restore the System State files to an alternate location, the AD
database, the Certificate Services database, and COM+ Class Registration database aren’t restored.
3. Once the restore is complete, restart the domain controller.
After the non-authoritative restore is complete, the restored data (which may be out of date) becomes synchro-
nized. Once you restart the domain controller, it should begin participating in AD replication and receive directory
updates from the other domain controllers.
You can use a non-authoritative restore if the domain controller fails or the entire AD database is corrupt because
you can simply restore the entire system data non-authoritatively. In more technical terms, this means that a non-
authoritative restore retains the original USN.
A non-authoritative restore provides a start point (the time at which the data was backed up) for data replication.
This minimizes the replication traffic on the network because only changed data is replicated rather than the entire
directory. In the absence of this start point, all data would be replicated from other servers.
While it’s possible to back up AD either online (while the directory services are running) or offline (when
the services are stopped), you can restore AD only when the directory services are offline.
Another option for restoring a Win2K domain controller is to simply re-install Win2K and reconfigure the
system as a domain controller on its domain. You can give the domain controller a different name, or if
you rebuild it with the same name, you need to first remove the old domain controller from the domain.
After you’ve done this, the normal AD replication process repopulates the domain controller with current
directory information.

Authoritative Restores
An authoritative restore allows you to recover a domain controller, restore it to a specific time, and mark objects in
AD as being authoritative with respect to their replication partners. For example, if an administrator inadvertently
deletes an organizational unit (OU) containing a large number of users, you can perform an authoritative restore to
recover the information and mark it as the source to force replication to the other domain controllers.
By definition, an authoritative restore replicates any changes made to the current data set to its outbound replica-
tion partners. To be the authoritative source for the restore, the authoritative restore modifies the USN of the AD
objects that are being restored to the domain controller so that each object has a higher value than any of those that
are currently on the domain controller. This forces the restored objects to be replicated to the other replicas of the
same domain controller.
Such a restore is unusual, but it has the effect of rolling back all of the AD objects in the domain controller to the
time of the original backup. You can do this to restore erroneously deleted information of a replicated set of data.
For example, if you inadvertently delete or modify objects stored in AD, you may want to authoritatively restore
them so that they can be replicated again to the other domain controllers. If you don’t authoritatively restore these
objects, they’re never replicated to the other domain controllers in the same domain because they appear to be older
than the objects currently on your domain controller.
To help you accomplish an authoritative restore, you can use the Ntdsutil utility to mark the target objects for
authoritative restore. This ensures that the data you want to be restored is replicated to the appropriate domain
controllers after the restore occurs. Table 6.3 describes the commands in Ntdsutil available to perform an authorita-
tive restore.
This Command Does This
Authoritative restore
(main menu option)
Allows you to use the authoritative restore submenu options listed below. You
can use this option only on a domain controller that is operating in Directory
Services Restore mode.
Restore database
(submenu option)
Marks the entire AD database (Ntds.dit) as authoritative.
Restore database verinc %d
(submenu option)
Marks the entire AD database (Ntds.dit) as authoritative and increments the
version number by %d. Use this option only to authoritatively restore over a
previous sequential authoritative restore.
Restore subtree %s
(submenu option)
Marks a subtree (all objects in the subtree) as being authoritative. The subtree
is defined by using the distinguished name (DN) of the OU object.
Restore subtree %s verinc %d
(submenu option)
Marks a subtree (all objects in the subtree) as being authoritative and incre-
ments the version number by %d. The subtree is defined by using the DN of
the OU object. Use this option only to authoritatively restore from a backup
that contains the objects you want to restore over.
Table 6.3: The Ntdsutil authoritative restore commands.

To perform an authoritative restore of AD on a specific domain controller:
1. Choose Start>Run or open a Command Prompt session.
2. Type Ntdsutil, then press Enter.
3. At the NTDSUTIL prompt, type Authoritative Restore, then press Enter. (This puts Ntdsutil into
Authoritative Restore mode.)
4. At the Authoritative Restore prompt, to set the entire database as authoritative, type Restore Database.
OR
To set only a subtree of the database as authoritative (for example, an individual OU), use the
Lightweight Directory Access Protocol (LDAP) DN that identifies the portion of AD being authorita
tively restored. For example, to authoritatively restore the Engineering OU in the
REALTIMEPUBLISHERS.COM domain, type the following:
RESTORE SUBTREE "OU=ENGINEERING,DC=REALTIMEPUBLISHERS,DC=COM"
5. When you’re prompted to confirm the authoritative restore, answer YES.
6. Type Quit, then press Enter twice to return to the command prompt.
7. Close the Command Prompt session.
Once AD is restored, be certain to answer No to the option to restart the server. This step is critical because the
restore will otherwise be non-authoritative when the server restarts, and you’ll risk re-inheriting unwanted data
from other AD replicas.
Always authoritatively restore SYSVOL whenever you authoritatively restore AD and vice-versa. This
ensures that SYSVOL and AD stay synchronized.
There are a few potentially negative consequences of authoritative restores that you should be aware of.
One such effect relates to trust relationships and computer account passwords. Both of these are automat-
ically negotiated at a specified interval (every seven days, by default, except for computer accounts that
can be disabled by the administrator). During an authoritative restore, a previously used password for the
objects in AD that maintain trust relationships and computer accounts can be restored. In the case of trust
relationships, this could void communication with other domain controllers from other domains. With com-
puter account passwords, this could void communications between the member workstation or server and a
domain controller of its domain. In this case, you may have to manually reestablish trusts to resume proper
communications.
Restoring FRS Data
I want to make a point about using Win2K’s backup utility to restore replicated FRS data sets as part of restoring a
domain controller. If you want to mark the restored data as the primary data for all replicas, you need to set a spe-
cial option that ensures that restored FRS data is replicated to your other servers. Specifically, when you restore
System State data, select the Advanced option to access the Advanced Restore Options dialog box, then select
When Restoring Replicated Data Sets, Mark the Restored Data As the Primary Data for All Replicas. If this domain
controller is a member of FRS replica sets other than the SYSVOL replica set, those other replica sets will also be
restored as authoritative. If you want to restore only the SYSVOL replica set, select the option in the backup utility;
then, after the restore is complete, delete the other replica sets.
If you don’t select this option, the FRS data that you’re restoring may not be replicated to other servers because the
restored data will appear to be older than the existing data. The other servers will overwrite the restored data, and
this will effectively prevent you from restoring the FRS data. Third-party backup applications also provide similar
options for performing primary restores.

Verifying Restores
Once you’ve restored AD, you can verify that it was successful. You can do this using either advanced verification or
basic verification. You must perform basic verification; advanced verification is optional, but you must run it before
you run basic verification.
Advanced
Advanced verification is optional; it isn’t usually required for normal recovery operations. You run it regardless of
whether you performed an authoritative restore. If you do run it, you must do so before you run basic verification.
Incorrectly using the Ntdsutil utility may corrupt the AD database, and you’ll have to restore the database from
backup again.
To perform advanced verification:
1. Make sure that you’re in Directory Services Restore mode.
2. Choose Start>Run.
3. In the Open dialog box, type Regedit, then click OK.
4. In REGEDIT, select the Registry key
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDS and check that it contains a
subkey called Restore In Progress. (This key is automatically generated by the Backup utility during the
restore and indicates to AD that the database files have been restored and need to be checked and re-
indexed the next time AD is started. When this check is completed, this key is automatically removed;
don’t manually add or delete it.)
5. Close REGEDIT.
6. To check for the recovered AD database files, start Ntdsutil by typing Ntdsutil at a command prompt or
in the Start>Run dialog box.
7. At the NTDSUTIL prompt, type Files. At the File Maintenance prompt, type Info. (If the AD files have
been recovered successfully, you can see the difference. Don’t select any other options.)
8. To exit File Maintenance, type Quit. To exit Ntdsutil, type Quit. To exit the DOS prompt, type Exit.
9. Restart the server in Normal mode. Log on to the system normally and perform basic verification (see
below).
Basic
Basic verification consists of rebooting and logging on normally, then confirming that the restored services are in a
state consistent with a successful restore. It also includes verifying that FRS and Certificate Services were successful-
ly restored.
To perform basic verification:
1. Restart the computer. (AD will automatically detect that it’s been recovered from a backup, perform an
integrity check, and re-index its database. Both AD and FRS will be brought up to date from their repli
cation partners using the standard replication protocols for each of those services.)
2. Confirm that distributed services successfully restored. (You should be able to browse AD and confirm
that all of the user and group objects that were present in the directory before the backup were restored.)
3. Confirm that files that were members of an FRS replica set and certificates that were issued by the
Certificate Service are present.

The Active Directory Backup Bug
There was a fairly serious bug in early versions of Win2K. This bug makes Win2K-based domain controllers unable
to start in AD mode after you restore System State backups that were created before installing Windows 2000
Service Pack 2. Restoring these backups to a Win2K domain controller leaves the directory services unable to start,
and the system records a number of errors in the system Event Log. The problem affects all applications that use
the backup APIs to perform AD backups; this includes System State backups performed with Win2K’s built-in
backup utility as well as most third-party backup applications.
Affected backups are corrupted in such a way that when they’re restored, they prevent the domain controller from
starting and cause it to display a "Directory Service cannot start" error message. Also, if you run Ntdsutil using the
Semantic Database Analysis option to run the database semantic checker, you receive error message 550: "Database
is inconsistent." With the backup utility, the problem happens even when the Verify option is turned on.
You can avoid these problems by installing SP2, then making new backups of the System State. The fix is preventa-
tive only; it doesn’t resolve errors that occur if you restore System State backups that contain incorrect header infor-
mation.
How It Occurs
As mentioned earlier in this chapter, you prepare for AD disaster recovery by making System State backups from
the console of Win2K-based domain controllers at regular intervals. The elements of AD that are captured in a
System State backup include the AD database (Ntds.dit), transaction logs (Edb*.log), and a patch file (Edb.pat).
You restore by starting Win2K domain controllers in Directory Service Repair mode and restoring the System State
using the Win2K backup utility, Ntbackup.exe, or a third-party equivalent. After performing the restore operation,
you can optionally use Ntdsutil.exe to mark specified domain name paths or subtrees as authoritative when the
domain controller next starts in AD mode.
The following conditions also contribute to this problem:
•An initial backup of AD is performed on a Win2K domain controller. During the backup, a number of
objects change as a result of either local changes or replication. The changes to these objects generate addi
tional transaction logs, which in turn advance the Joint Engine Technology (Jet) database checkpoint. The
Jet checkpoint maintains a list of unflushed data in the database. Two copies of the checkpoint data are
stored: One in the database header of the Ntds.dit file and a second in-memory copy, which is written to
the backup media.
•A second backup is performed on another, relatively inactive domain controller. During the backup, the
log files aren’t generated, and the Jet checkpoint isn’t advanced. This second backup completes before the
log files are generated and the Jet checkpoint advances in the first backup.
•The second backup is then restored.
In order for the problem to manifest itself, the new transaction logs and Jet checkpoint advancement that occur
during the first backup must happen after the second backup completes. As a result, a relatively large first backup is
more likely to produce the problem because there is a commensurately larger window of time for the second back-
up to complete (and for the Jet checkpoint to advance). Domain controllers in busy production environments are
less likely to experience this problem during typical activity (creating, deleting, and modifying objects) because
these activities in AD result in a steady advance of the Jet checkpoint.

The problem is more likely to occur in large backups (or when the backup media doesn’t have a fast backup rate)
because the backup process takes longer and there is more opportunity for the checkpoint file to advance. The
essential problem is that a second backup is made before the checkpoint file advances, then the second backup is
restored.
The result of all this, and the core of the problem, is that an outdated record of required transaction log files and
checkpoint data is written to the backup media, then later restored as the second backup. The header in the
restored database references logs that aren’t actually required for the AD recovery and that aren’t all included in the
backup. This explains why log entries appear stating, "Log files are missing from System State." However, such
entries are misleading because it isn’t a case of the log files being missing; instead, the number of log files referenced
in the restored database header is incorrect.
Working Around It
If you use backups as a method of recovery for Win2K-based domain controllers, you may want to consider doing
the following to work around the bug:
•Inventory, then clearly label backups that were made before installing SP2. Place pre-SP2 backup media in
locked storage. Don’t forget backup media that are stored on the local drives of computers in your organi
zation.
•Consistent with good change-management practices, install SP2 on domain controllers in a lab environ
ment that is representative of your production configuration. Make multiple backups, then initiate restore
tests.
•Install SP2 on production domain controllers. Create new System State backups and clearly label them as
post-SP1 backups.
•Destroy pre-SP2 backups.
Repairing a Domain Controller in Active Directory
If a Win2K domain controller fails, you have several options for repairing it. You might need to use more than one
or even all of them.
•Use the ERD to either prepare a set of disaster-recovery disks, or use a set of previously established disks to
repair specific components of a domain controller so that it can successfully start up. Log on using an
account that has Administrator or Backup Operator privileges.
•Re-install the Windows 2000 Server OS and run the Active Directory Installation Wizard. If a major hard
ware failure or malfunction requires the computer to be completely rebuilt, you may need to re-install the
OS. After the computer is running, reconfigure the original network connections and DNS settings.
•If you need to remove a domain, run the Active Directory Installation Wizard to remove AD from all
domain controllers that you’re removing. Then use the NETDOM utility to remove the domain itself
(including cross-reference and trusted domain objects). To do this, type the following at the command
prompt:
netdom trust /remove /force
•To clean up metadata that has been left behind by decommissioned or failed domain controllers, you can
use Ntdsutil with the CLEANUP command. This operation removes the defunct domain controller’s
identification and information from AD.

Summary
The guidelines for backing up and restoring Win2K servers and domain controllers include information for
Win2K and AD. You can use the Win2K backup utility to back up and restore data and perform emergency recov-
eries. To back up and restore a failed server to an operational state, you use the backup utility’s Backup and Restore
wizards.Alternatively, you can back up and restore selected user files and folders on the domain controller’s hard
drive.
You can back up and restore the domain controller’s System State—the files central to system operation; they
include the Registry, AD and SYSVOL, the COM+ Class Registration database, and boot files. You can also sched-
ule regular backups and create an ERD that helps you repair system files should your system become corrupted.

Without Sean Daily, The Definitive Guide to Active Directory Troubleshooting wouldn't be a definitive guide at all.
Sean has been running Active Directory since early beta, and he knows it inside and out. Check out his beefy bio
below! And, don't miss the backgrounder on the company he writes for. NetPro's ebook is the second comprehensive
guide published by Realtimepublishers.com that's free and available on the web - and it won't be the last!
Sean Daily is a world-renowned expert on Windows NT/2000 and a Senior Contributing Editor at Windows 2000
Magazine. In addition to being the author of numerous books, including The Definitive Guide to Windows 2000
Administration (Realtimepublishers.com) and Optimizing Windows NT (IDG/Hungry Minds), Sean speaks and
consults internationally on Windows NT/2000 and related technologies. Sean also serves as Series Editor for
Realtimepublishers.com's Definitive Guide and Tips and Tricks Guide series of ebooks.
About the Tech Editor
NetPro's own Chief Scientist, Gil Kirkpatrick, performed the technical edits for the ebook. Kirkpatrick is an expert
in the design and development of large-scale distributed software for enterprise networks and has over 24 years of
industry related experience. He is a recognized authority on commercial network directories, including Banyan's
StreetTalk, Novell's NDS eDirectory and Microsoft's Active Directory. In his previous position as NetPro's Director
of Engineering, Kirkpatrick was responsible for the development of NetPro's directory management products and
served as the architect and lead engineer for NetPro's flagship product, DirectoryAnalyzer. Kirkpatrick joined
NetPro in 1994 when NetPro acquired his company, High Technology Systems. Kirkpatrick is also the author of
Active Directory Programming, published by MacMillan USA.
The Definitive Guide to Active Directory Troubleshooting About the Author
About the Author

Complete ad troubleshooting

More Related Content

What's hot

Similar to Complete ad troubleshooting

Recently uploaded

Complete ad troubleshooting