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.

Complete ad troubleshooting

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Complete ad troubleshooting

Similar to Complete ad troubleshooting (20)

Recently uploaded

Recently uploaded (20)

Complete ad troubleshooting