NetPro AD DFN Gde 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 Defi ni t i ve Gui de t o Act i ve Di rect ory Troubl eshoot i ng Foreword
Foreword by Pet er Houst on
Chapt er 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
ADs 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
Chapt er 2
Designing an Effective Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Active Directorys 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 Defi ni t i ve Gui de t o Act i ve Di rect ory Troubl eshoot i ng t abl e of cont ent s
Tabl e of Cont ent s
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 Companys 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
Chapt er 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
Chapt er 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
Chapt er 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 Doesnt 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 Kits 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
Chapt er 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 Wont 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 Defi ni t i ve Gui de t o Act i ve Di rect ory Troubl eshoot i ng Int roduct i on
eBook Int roduct i on
The Defi ni t i ve Gui de t o Act i ve Di rect ory Troubl eshoot i ng
Chapt er 1
Int roduci ng Act i ve Di rect ory
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 Microsofts 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-hi erarchi cal st ruct ure and namespace
NTs directory used a flat, non-hierarchical directory structure that didnt support the naming and structural
needs of complex organizations.
Lack of ext ensi bi l i t y
NTs directory stored only basic user information and couldnt be inherently extended.
Lack of scal abi l i t y
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 manageabi l i t y feat ures
Administration roles werent layered and couldnt be natively delegated.
Poor di rect ory repl i cat i on per formance
Because NTs architecture was bandwidth- and network topology-ignorant, the NT operating system couldnt
automatically tune replication frequency and bandwidth usage to adapt to variable WAN link speeds
between multiple physical locations within a network.
Si ngl e-mast er, Si ngl e poi nt of fai l ure archi t ect ure
NTs 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), NTs successor OS, Microsoft set out to deliver a directory capable of addressing each
of these limitations. Win2Ks new directory service, dubbed Active Directory (AD), provides an industrial-strength
Chapt er 1 www.net pro.com 1
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 Banyans StreetTalk and Novells NDS have existed for some time, many
Windows NT-centric organizations have opted to wait and use Microsofts entry in the enterprise directory arena
as the foundation for their organization-wide directory environment. Consequently, Win2Ks Active Directory will
represent the first foray into the larger world of directories and directory management for many organizations and
network administrators.
The Impor t ance of Di rect ori es and Di rect ory 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 Win2Ks 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 Tool s for New Ti mes
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 Win2Ks 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 Act i ve Di rect ory
Of all of the elements that comprise a Win2K network, the most important by far is the Active Directory, Win2Ks
centralized directory service. However, before we delve into the specifics of Win2K and the Active Directory, lets
first define some of the fundamental terms and concepts related to directory-enabled networks. A directory (which
is sometimes also referred to as a data store) maintains data about objects that exist within a network, in a hierarchical
structure, making the information easier to understand and access. These objects include traditional network
resources such as user and machine accounts, shared network resources (such as shared directories and printers), 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 Microsofts Active
Directory and Novells 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 not able except ion t o t his and is complet ely int egrat ed wit h Act ive Direct or y.
Exchange 2000 s inst allat ion process ext ends Act ive Direct or y s st ruct ure t o accommodat e Exchange-spe-
cific dat a and subsequent ly uses AD t o st ore it s own direct or y informat ion.
Active Directory is Microsofts 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 t erm mult i-mast er indicat es t hat mult iple read/ writ e copies of t he dat abase exist simult aneously, on
each Win2K domain cont roller comput er. Thus, each Win2K domain cont roller is ef fect ively an equal peer of
t he ot her cont rollers, and any cont roller can writ e direct or y updat es and propagat e t hose updat es t o ot her
cont rollers. This is in not able cont rast t o NT 4.0 s single-mast er PDC/ BDC replicat ion t opology wherein a
single domain cont roller, t he PDC, houses a read/ writ e copy of t he dat abase.
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 Dat abase
At a file system level, the Active Directory uses Microsofts 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 Directorys 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 Exchanges 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 directorys 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.
Logi cal Archi t ect ure of AD
To gain an appreciation for and understanding of AD and AD management concepts, its important to first under-
stand ADs logical architecture. In this section, well discuss the most important concepts associated with AD, con-
cepts which form the foundation of all Win2K networks.
Obj ect s and At t ri but es
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 t ypes of object s in AD known as cont ainer object s t hat you should be familiar wit h. 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.
Alt hough it s per fect ly accept able t o say " creat e" in lieu of " inst ant iat e" when referring t o t he generat ion of a
new object wit hin t he direct or y, we ll use t he lat t er more frequent ly in t his book. The reason is t hat inst ant iat e
is more appropriat e when you consider t he underlying event t hat act ually occurs -- t hat being t he " creat ion of
an inst ance of" an object . And, hey, let s face it : saying inst ant iat e sounds a lot cooler and is more likely t o
impress people (just kidding if we really believed t hat we d st ar t t hrowing around words like or t hogonal!)
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 t he Act ive Direct or y schema it self is st ored in t he direct or y as object s. That is, AD classes are st ored
as object s of t he class " classSchema" and at t ribut es are st ored as object s of class " at t ribut eSchema" . The
schema, t hen, is just a number of inst ances of t he classes " classSchema" and " at t ribut eSchema" , wit h
proper t ies t hat describe t he relat ionship bet ween all classes in t he AD schema.
To understand the relationship between object classes, objects, and the schema, lets go back to the object-oriented
model upon which the AD schema is based. As is the case with object-oriented development environments (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 engines 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 t he Act ive Direct or y Schema using t he 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.
Vi ewi ng t he AD Schema
Some of you may be curious at t his point how t o use t he AD Schema MMC snap-in shown in Figure 1.1 t o view t he
AD schema. It s not immediat ely obvious how t o do t his using t he MMC console, since AD Schema isn t available in
t he default list of snap-ins t hat appears. One not e of caut ion here: edit ing t he schema is a pot ent ially dangerous
act ivit yyou need t o know exact ly what you re doing and why you re doing it . Before you make schema changes, be
sure t o back up t he current AD dat abase cont ent s and schema (e.g., by using nt backup.exe or a t hird-par t y ut ilit y s
Syst em St at e backup opt ion on an up-t o-dat e domain cont roller).
To view t he AD schema, use t he Microsoft Management Console (MMC) Act ive Direct or y Schema snap-in, which
you ll find among Win2K s Suppor t Tools. (You can inst all t hese t ools from t he Win2K CD-ROM s \ suppor t folder.) To
use t his snap-in, you need t o manually regist er t he snap-in by select ing St ar t , Run (or ent ering a command-prompt
session) and t yping:
regsvr32 schmmgmt .dl l
You ll receive a message stating that the OS successfully registered the .dll file. You can now load and use the Active
Director y 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 Director y Schema from the Add Standalone
Snap-In dialog box (Figure 1.1 shows the Active Director y Schema snap-in s view of the AD schema).
To modify the AD schema, you need to use a dif ferent 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 registr y editors are to the system registr y. 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 conver ted to Win2K s native mode). To use the snap-in, first register the associated
adsiedit.dll file at the command line:
regsrv32 adsi edi t .dl l
The ADSI Edit snap-in will be available from t he MMC s Console/ Add/ Remove snap-in menu. Once you ve added
t he snap-in, you can use t he ADSI Edit console t o make changes t o AD object s and at t ribut es.
For a more advanced discussion of t he AD schema and it s underlying const ruct s, I recommend The Definit ive
Guide t o Win2K Administ rat ion by Sean Daily and Darren Mar-Elia. Chapt er 1 of t his book describes advanced
AD schema design and management issues. You can find a link t o t his free eBook by Realt imepublishers.com
at ht t p:/ / www.realt imepublishers.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.
Act ive Direct or y suppor t s LDAP versions 2 and 3.
Table 1.1. LDAP name component s.
At t ri but e Type
Domain-Component
Organizational-Unit-Name
Descri pt i on
An individual element of the DNS domain name of the objects
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 domains Marketing OU would be as follows:
CN=David Templeton,OU=Marketing,DC=realtimepublishers,DC=com
The above form of an objects name as it appears in the directory is referred to the objects 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 Abbrevi at i on
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.
Domai ns, Trees, and Forest s
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 ADs logical structure, and is defined as a collection of computers that share a common
directory database. In fact, this definition is basically identical to that of NT domains. Like NT domains, 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 t o be Int ernet -regist ered domain names ending in Int ernet -legal t op-level
domains, such as .com, .org, .net , et c. For example, it is possible t o name domains wit h endings such as
.priv, .msft , or some ot her ending of your choosing. This of course assumes t hat t he domain s DNS ser vers
aren t par t icipat ing in t he Int ernet DNS namespace hierarchy (which is by far t he most common scenario, due
t o securit y considerat ions wit h exposing int ernal DNS ser vers t o t he Int ernet ). If you do elect t o use st andard
Int ernet t op-level domains in your Win2K domain names, you should regist er t hese names on t he Int ernet
even if t hey don t par t icipat e in t he Int ernet DNS namespace. The reason for t his is t hat most organizat ions
are connect ed t o t he Int ernet , and using unregist ered int ernal domain names t hat may pot ent ially be
regist ered on t he Int ernet could cause name conflict s.
Win2Ks 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 (well 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 Act ive Direct or y forest wit h a single t ree.
The Kerberos Version 5 aut hent icat ion prot ocol is a dist ribut ed securit y prot ocol based on Int ernet st andards,
and is t he default securit y mechanism used for domain aut hent icat ion wit hin or across Win2K domains.
Kerberos replaces Windows NT LAN Manager (NTLM) aut hent icat ion used in Windows NT Ser ver 4.0, as t he
primar y securit y prot ocol for access t o resources wit hin or across Win2K Ser ver domains. Win2K domain
cont rollers st ill suppor t NTLM t o provide backward compat ibilit y wit h Windows NT 4.0 machines.
Figure 1.3: Example of a mult i-t ree Act ive Direct or y forest .
In t he case of a forest wit h mult iple t rees, t he name of t he forest is t he name of t he first domain creat ed
wit hin t he forest (i.e. t he root domain of t he first t ree creat ed in t he forest ).
Al t hough cohabi t at i on of di f f erent organi zat i ons wi t hi n t he same AD f orest i s appropri at e i n some ci rcum-
st ances, i n ot hers i t i s not . For exampl e, uni que securi t y or schema needs may requi re t wo compani es t o
use ent i rel y di f f erent AD f orest s. In t hese si t uat i ons, Kerberos t r ust s aren t est abl i shed bet ween t he t wo
f orest s but you may creat e expl i ci t t r ust s bet ween i ndi vi dual domai ns i n di f f erent f orest s.
There are several resources you mi ght f i nd hel pf ul when pl anni ng your organi zat i on s AD st r uct ure and
namespace. One i s The Def i ni t i ve Gui de t o Act i ve Di rect or y Desi gn and Pl anni ng, anot her f ree eBook f rom
Real t i mepubl i shers. com (a l i nk t o whi ch can be f ound at ht t p: / / www. real t i mepubl i shers. com). There are
al so several Mi crosof t whi t e papers t hat cont ai n val uabl e i nf ormat i on on AD desi gn and archi t ect ural
concept s, i ncl udi ng " Act i ve Di rect or y Archi t ect ure" and " Domai n Upgrades and Act i ve Di rect or y. " These
and ot hers t echni cal document s rel at ed t o AD can be f ound on Mi crosof t s Web si t e at
ht t p: / / www. mi crosof t . com/ wi ndows2000/ ser ver.
Organi zat i onal Uni t s
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 t he design of OU hierarchies wit hin domains, but t he t wo most
common are t hose dividing t he domain organizat ionally (e.g. by business unit ) or geographically.
An example of OUs within a domain is shown in Figure 1.4.
Figure 1.4: Organizat ional unit s (OUs) wit hin a domain.
The Gl obal Cat al og
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:
Net work l ogon aut hent i cat i on
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).
Di rect ory searches and queri es
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 impor tant in facilitating director y queries and searches on these networks and
should therefore be made available at each site within the network.
Physi cal St ruct ure of AD
Thus far, our discussion of AD has focused on the logical components of the directorys architecture; that is, the
components used to structure and organize network resources within the directory. However, an AD-based network
also incorporates a physical structure, which is used to configure and manage network traffic.
Domai n Cont rol l ers
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.
For t unat ely, Win2K does away wit h NT s rest rict ion t hat conver t ing a domain cont roller t o a member ser ver or
vice-versa requires reinst allat ion of t he ser ver OS. In Win2K, ser vers may be promot ed or demot ed t o domain
cont roller st at us dynamically (and wit hout reinst allat ion) using t he Dcpromo.exe domain cont roller promot ion
wizard.
At least one domain controller must be present in a domain, and for fault tolerance reasons its a good idea to have
more than one domain controller at any larger site (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.
Di rect ory Repl i cat i on
As weve 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.0s
single-master PDC/BDC replication topology wherein a single domain controller, the PDC, houses a read/write
copy of the database.
AD s replicat ion design means t hat dif ferent domain cont rollers wit hin t he domain may hold dif ferent dat a
at any given t ime but usually only for shor t periods of t ime. As a result , individual domain cont rollers may
be t emporarily out of dat e at any given t ime and unable t o aut hent icat e a login request . Act ive Direct or y s
replicat ion process has t he charact erist ic of bringing all domain cont rollers up t o dat e wit h each ot her; t his
charact erist ic is called " convergence" .
The Operat i ons Mast ers
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 mast er
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 forests schema can only be done by members of the
Schema Administrators group, and can be done only on the domain controller that holds the schema master role.
Domai n nami ng mast er
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 emul at or
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 Win2Ks Kerberos security mechanism), and processing account lockouts and client pass
word changes.
RID mast er
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.
Infrast ruct ure mast er
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, its essential for proper
network operation that all the servers hosting these roles are continually available.
Si t es
The final, and perhaps most important component of ADs physical structure is a site. Sites allow administrators to
define the physical topology of a Win2K network, something that wasnt 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. Its also possible to group multiple, non-contiguous IP subnets together to
form a single site.
So, why are sites important? The primary reason is that the definition of sites makes it possible for AD to gain
some understanding of the underlying physical network topology, and tune replication frequency and bandwidth
usage accordingly (under NT, this could only be done via manual adjustments to the replication service). This
"intelligence" conferred by the knowledge of the network layout has numerous other benefits. For example, it
allows AD-enabled computers hosting users who are logging 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.
Its important to remember that sites are part of the physical structure of AD and are in no way related to the logical
constructs weve already discussed, such as domains and OUs. Its possible for a single domain to span multiple
sites, or conversely for a single site to encompass multiple domains. The proper definition of sites is an essential
aspect of AD and Win2K network design planning.
For sit es t hat house mult iple domains (e.g. an organizat ion t hat divides business unit s int o domains rat her
t han OUs, t hus host ing mult iple business unit domains on a single sit e), it s impor t ant t o remember t o place
at least one, and possibly t wo, domain cont rollers for each domain t hat users will aut hent icat e t o from t hat
sit e. This out lines t he biggest disadvant age of t he business unit domain model: t he pot ent ial for requiring
many domain cont rollers at each and ever y sit e.
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 hosts 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 systems FQDN indicates its position within the DNS
hierarchy. For example, the FQDN of a computer named mercury located in the domain realtimepublishers.com
would be mercury.realtimepublishers.com.
Although it is possible to incorporate a DNS namespace within 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 networks DNS namespace.
This namespace duplicat ion will normally be limit ed t o t he int ernal DNS namespace for companies using t he
Microsoft -recommended configurat ion of separat e DNS configurat ions for t he int ernal LAN and t he Int ernet .
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.
Its 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 doesnt 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).
Int roduct i on t o AD and Wi n2K Moni t ori ng
As youve 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:
Li mi t ed or no proact i ve moni t ori ng procedures i n pl ace.
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.
Exi st i ng moni t ori ng procedures i n pl ace usi ng home-grown or bui l t -i n t ool s.
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.
Exi st i ng moni t ori ng procedures i n pl ace wi t h ful l -feat ured net work moni t ori ng t ool s.
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, youll 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
NTs simpler (and less capable) network architecture. Lets quickly review the primary monitoring considerations in
a Windows NT environment are as follows:
PDC avai l abi l i t y and per formance
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.
Domai n t rust rel at i onshi ps
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.
Net work browser servi ce
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.
Ot her cri t i cal servi ces and appl i cat i ons
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.
Basi c net work and syst em met ri cs
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 Wi n2K Moni t ori ng Consi derat i ons
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.
Its 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 Consist ency Checker (KCC) is a special Win2K ser vice t hat aut omat ically generat es Act ive
Director y s replication topology, and ensures that all domain controllers on the network par ticipate in replication.
However, knowing what metrics to monitor is only a first step. By far, the most important and complex aspect of
monitoring network health and performance isnt related to determining what to monitor, but rather how to digest
the raw data collected from the array of metrics and make useful determinations from that data. For example,
although it would be possible to collect data on several dozen metrics (e.g. via Performance Monitor) related to
Active Directory replication, simply having this information at hand doesnt tell you how to interpret the data, or
what you should consider acceptable tolerance ranges for each metric. A useful monitoring system not only collects
raw data, but also understands the inter-relation of that data and how to use the information to identify problems
on the network. This kind of artificial intelligence represents the true value of network monitoring software.
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.
Cat egory
Domain Controllers/Active
Directory
Pot ent i al Probl ems
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 Moni t ori ng and Audi t i ng
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, its essential that a system be in
place to identify all recent changes made to objects within the directory, and to be able to ascertain who did 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).
Probl em Resol ut i on, Aut omat i on, and Al er t i ng
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 Act ive Direct or y-based Win2K Net works.
Many tools use scripting and/or the ability to call external utilities to accomplish these tasks. The most comprehensive
utilities base their decisions on rule sets derived from an internal database and/or intelligent escalation routines that
emulate what an administrator might do. For example, you might configure a system such that on the first failure
of a given service, that service is restarted; the computer is restarted in the event the service restart fails; a different
machine is promoted to replace that system in the event the computer restart attempt fails, and so on.
Ot her Consi derat i ons
There are several considerations you should keep in mind when creating a Win2K network monitoring and
troubleshooting solution. One is the overall architecture of the application(s) being used in the solution. Its
important to understand how the product collects its data and what impact this collection will have on your
network and servers. For example: Does the product employ local agents to gather metrics or does it use remote
queries? Do throttling features exist to control network bandwidth and system resource usage? Is there a
machine/site/domain hierarchy that allows data to be passed to the central collection database in an efficient
manner? Does the product provide web-based management? All of these questions are important since they can
have a significant impact on your network environment and your overall satisfaction with the product.
Another differentiating feature about network monitoring software packages is whether or not they provide a support
knowledgebase of common problems and solutions. This kind of knowledge is invaluable from both a technical
and financial standpoint, since it serves to reduce the learning curve of the supporting IT staff, as well as the
amount of time and money administrators must expend researching and resolving problems. Some utilities augment
this capability by allowing administrators to add their own experience to the knowledgebase or a problem tracking
and resolution database, thereby leveraging internal IT staff expertise and creating a comprehensive problem
resolution system.
A final feature provided by some applications, and one that may be of interest to IT shops engaged in Service Level
Agreements (SLAs), is the ability to generate alerts and reports that address exceptions to, or compliance with SLA
obligations.
Summary
Although Win2K and Active Directory represent a quantum leap forward in the NT product line, they also introduce
new levels of network infrastructure complexity that must be properly managed in order to maintain an efficient and
highly available network. Real-time, proactive monitoring and management of the Active Directory and other critical
services is an essential part of managing Win2K-based networks. In this chapter, we discussed the most important
features and components of Win2K and Active Directory, their roles within the enterprise, differences between
managing Windows NT 4.0-based networks and Win2K Active Directory-based networks, and some of the basic
metrics and statistics that Win2K network administrators need to watch to help them ensure high availability on
their networks.
In the remaining chapters of this book, well drill down and explore each of the vital areas of Active Directory and
Win2K networks in detail, providing the information, tools, and techniques youll need to employ to maintain a
healthy and highly available Win2K network.
eBook Copyri ght Not i ce
This sit e cont ains mat erials creat ed, developed, or commissioned by Realt imepublishers.com, Inc. and is prot ect ed by
int ernat ional copyright and t rademark laws. No mat erial (including but not limit ed t o t he t ext , images, audio, and/ or
video) may be copied, reproduced, republished, uploaded, post ed, t ransmit t ed, or dist ribut ed in any way, except t hat one
copy may be downloaded for your personal, non-commercial use on a single comput er. In connect ion wit h such use, you
may not modify or obscure any copyright or ot her propriet ar y not ice. If you have any quest ions about t hese t erms, or if
you would like informat ion about licensing mat erials from Realt imepublishers.com, please cont act us via e-mail at
info@realt imepublishers.com
Chapt er 2
Desi gni ng an Ef f ect i ve Act i ve Di rect ory
The main function of Active Directory (AD) is to allow the network resources for Windows 2000 (Win2K) to be
identified and accessed. AD accomplishes this goal by providing a single namespace where users and applications
can go to register and gain access to the information they need. AD can be set up and designed in many different
ways to meet the needs of users and administrators. Its your job as an administrator to properly set up and design
your AD for maximum efficiency.
The best way to troubleshoot AD problems is to avoid AD problems in the first place. To do that, you need to start
with a good design. The design of AD not only includes the layout of the forests, trees, domains, and Organizational
Units (OUs) but also the site and site links that represent the physical network.
In this chapter, Ill give you a solid understanding of how to design an AD for your environment and network.
Because the information in AD can be distributed across the network, there may be unique aspects of your design
and implementation that only apply to your site. However, my goal is to give you enough information to ensure
that the design serves the needs of your users and administrators.
Act i ve Di rect ory s Logi cal and Physi cal St ruct ures
As I mentioned in Chapter 1, AD has internal structures that can be categorized as logical and physical. These
structures are the building blocks youll use to design and build your AD service. Your challenge is to understand
each building block and use it to build an efficient AD. The concepts behind these structures are sometimes not
easy, but understanding them and using them correctly are the keys to a good design.
Logi cal St ruct ures
A list of logical structures used in AD is shown in Table 2.1.
Namespace AD is a namespace because it resolves an objects name to the object itself.
Naming context Represents a contiguous subtree of AD.
Organizational Unit A container object that allows you to organize your objects and resources.
Domain A partition in AD that provides a place to group users, groups, computers,
printers, servers, and other resources together.
Tree A grouping of domains.
Forest A collection of one or more trees.
Trust relationship A logical connection between two domains that forms one administrative unit.
Global catalog A central source for AD queries for users and other objects.
Logi cal St ruct ure Descri pt i on
Table 2.1: The logical st ruct ures of AD, which are used t o design and build t he object hierarchy.
Two important logical structures that you need understand to design an AD are the namespace and naming context.
Although these two concepts seem to mean the same thing, theyre actually different. To help you understand how
they differ, Ill give you a quick overview of each. These structures are also discussed throughout the chapter.
Namespace
Another term for a directory is namespace. A namespace refers to a logical space in which you can uniquely resolve
a given name to a specific object in the directory. AD is a namespace because it resolves a name to the object name
and the set of domain servers that stores the object itself. Domain Name System (DNS) is a namespace because it
translates easy-to-remember names (such as www.company.com) into an IP number address (for example,
124.177.212.34).
Nami ng Cont ext
The naming context represents a contiguous subtree of AD in which a given name is resolved to an object. If you
look at the internal layout of AD, you see a structure that looks similar to a tree with branches. If you expand the
tree, you see the containers, the objects that reside in them, and the attributes associated with the objects.
In AD, a single domain controller always holds at least three naming contexts.
Domai n
Contains the object and attribute information for the domain of which the domain controller is a member
Confi gurat i on
Contains the rules for creating the objects that define the logical and physical structure of the AD forest
Schema
Contains the rules for creating new objects and attributes.
AD depends on DNS and t he DNS-t ype namespace t hat names and represent s t he domains in t he forest . It s
impor t ant t o design your domain t ree in a DNS-friendly way and t o provide client s wit h reliable DNS ser vices.
Alt hough AD uses DNS t o creat e it s st ruct ure, DNS and AD are t ot ally separat e namespaces.
Physi cal St ruct ures
In addition to the logical structures in AD, several physical structures help you implement the logical structures on
your network. These physical structures are listed in Table 2.2.
Desi gni ng Act i ve Di rect ory
Your primary objective in designing AD is to build a system that reflects the network resources in your company.
You need to arrange the forest and trees to reflect the location and placement of your network resources. You need
to design the domains and OUs to implement an administrative and security structure for both users and
administrators. When designing the layout of AD, you also need to design the users groups and security policies
as well as the administrative methods you used.
From the list of logical and physical structures that you have to work with, four structures are critical to the design
of AD: forests and trees, domains, OUs, and sites. Designing and implementing each of these four structures builds
on the previous one. Implementing these structures properly is crucial to a successful design. Design your AD
structure in the following order:
1. Design the forest and trees
2. Design the domains for each tree
3. Design the OUs for each domain
4. Design the sites for the forest and domains.
In the next four sections, Ill describe how to design each of these main structures.
Desi gni ng t he Forest and Trees
A forest is a collection of one or more trees. A forest can also be a set of domain trees that doesnt form a common
naming context. The trees in a forest share the same directory schema and configuration but dont need to share the
same namespace. For example, a single directory can contain two companies or organizations. Figure 2.1 illustrates
how two companies named company1.com and company2.com form a single forest.
Object and attributes An object is defined by the set of attributes or characteristics assigned to it.
Objects include users, printers, servers, groups, computers, and security policies.
Domain controller A network server that hosts AD in a domain.
Directory server role A server that takes the role of Flexible Single Master Operation (FSMO).
Directory server roles are single-master servers that perform special roles for
AD, such as managing domains, managing schemas, and supporting down-level
clients (Windows NT).
Site A location on the physical network that contains AD servers. A site is defined as
one or more well-connected Transmission Control Protocol/Internet Protocol
(TCP/IP) subnets.
Global catalog server Stores the global catalog information for AD.
Physical Structure Description
Table 2.2: The physical st ruct ures of AD, which are used t o implement t he logical direct or y st ruct ures on t he net work
Figure 2.1: Two companies or organizat ions named company1.com and company2.com can form a forest in AD.
The forest serves two main purposes. First, it simplifies workstation interaction with AD because it provides a global
catalog where the client can perform all searches. Second, the forest simplifies administering and managing multiple
trees and domains. A forest has the following key characteristics or components:
Gl obal Schema
The directory schema for the forest is a global schema, meaning that its exactly the same for each domain controller
in the forest. The schema exists as a naming context and is replicated to every domain controller. The schema
defines the object classes and the attributes of object classes.
Gl obal Confi gurat i on Cont ai ner
The configuration container exists as a naming context that is replicated to every domain controller in the forest.
Thus, its exactly the same across the domain controllers in the forest. The configuration container contains the
information that defines the structure of the forest. This information includes the domains, trust relationships,
sites, site links, and the schema. By replicating the configuration container on every domain controller, each domain
controller can reliably determine the structure of the forest, allowing it to replicate to the other domain controllers.
Compl et e Trust
AD automatically creates bi-directional transitive trust relationships among all domains in a forest. This allows the
security principals, such as users and groups of users, to authenticate from any computer in the forest. However,
this is only true if the users access rights have been set up correctly.
Gl obal Cat al og
The global catalog contains a copy of every object from every domain in the forest. However, it only stores a select
set of attributes from the objects. By default, the global catalog isnt placed on every domain controller in the forest;
instead, you determine which domain controllers should hold a copy.
When designing the forest, you need to consider both the users and the administrators. For example, consider an
organization that has just acquired another company. If the two forests are merged into a single forest, all the users
can view the entire AD. However, the forests might not be merged because the two autonomous administrative
groups might not agree on how to manage the forests. The winner of this dispute depends on your priority: Do
your users have a higher priority than your administrators?
If the administrators win, the users inherit two forests and no longer have a single, consistent view of AD. Each
administrative group manages its own forest independently.
The answer also depends on which type of organization your company is. If it isnt important for the users to have
a consistent view of AD, it might be appropriate to have multiple forests with separate administrators. For example,
consider an application service provider (ASP) company, which hosts AD services on behalf of other companies. The
users from those companies have no reason to view the host companys information. In addition, each administrative
group wants its independence.
Det ermi ni ng t he Number of Forest s
When determining the number of forests for your company, consider the requirements of the organization itself. In
smaller, centrally managed organizations, you typically need one forest. However, if the company is large and has
multiple locations in one or multiple countries, you probably need multiple forests. To properly determine the
number of forests for your company, you need to understand the maintenance and overhead of having one forest
compared to multiple forests.
An environment with a single forest is simple to create and maintain. All users view one AD using the global catalog.
Maintaining a single forest is easy because you only need to apply configuration changes once to affect all the domains
in the forest. For example, when you add a domain to the forest, all the trust relationships are set up automatically.
In addition, the new domain receives any additional changes made to the forest.
When deciding on the number of forests you need, remember that a forest has shared elements: the schema,
configuration container, and global catalog. Thus, all the administrators need to agree on their content and
management. Managing these elements becomes more complicated when you add a forest because it incurs a
management cost. The following is a brief list of the many management issues surrounding multiple forests:
Each additional forest must contain at least one domain, domain controller, and someone to manage it.
Each additional forest creates a schema. Maintaining consistency among schemas is difficult and creates
overhead.
Each additional forest creates a configuration container. Maintaining consistency among configuration
containers when the network configuration changes is difficult and creates overhead.
If you want user access among forests, you must create and maintain explicit one-way trusts for every
relationship you establish.
Users wanting access to resources outside their forest need to make explicit queries; this is difficult for the
ordinary user.
Any synchronization of components among multiple forests has to be done manually or using a
metadirectory service or other synchronization solution.
Users cannot easily access the network resources contained in other forests.
Set t i ng Up and Managi ng Mul t i pl e Forest s
Having to set up and manage two forests might be necessary if two organizations in a company dont trust one
another or cannot agree on administrative policies. For example, lets say a company has two locations in different
countriesNew York and London. Each location has its own administrative group, which needs to manage its
network resources according to its own policies. In this case, two different forests can be used to separate the
administrative requirements.
In other situations, your company might have multiple forests, but you want to have a central administrative
group. To set up central management of multiple forests, you need to add administrators to the Enterprise and
Schema Administration groups of each forest. Because there is only one Enterprise and Schema Administration
group per forest, you must agree on a central group of administrators who can be members of these groups.
As mentioned previously, its difficult to manage user access between two or more forests. The simplest method is
to create explicit one-way trusts among the domains that must trust one another. The one-way trust only allows
access among the domains in the direction that its set up. This approach of connecting the forest is shown in
Figure 2.2.
One sit uat ion in which you may consider managing mult iple forest s occurs when t wo organizat ions merge or
par t icipat e in a joint vent ure. This put s t he administ rat ion of your net work int o t he hands of t wo aut onomous
groups. For t his reason, mult iple t rees are t ypically more cost ly t o manage. To reduce t his cost , organizat ions
such as par t nerships and conglomerat es need t o form a cent ral group t hat can drive t he administ rat ive
process. On t he ot her hand, in shor t -lived organizat ions like joint vent ures, it might not be realist ic t o expect
administ rat ors from each organizat ion t o collaborat e on forest administ rat ion.
There is another good example of a situation where multiple forests may be required. Many enterprise
organizations elect to maintain separate, parallel AD forests for testing purposes. Other organizations maintain
multiple forests because they have a disjointed organizational structure with no common infrastructure among
business units. Although you ll cer tainly want to keep your network and AD design as simple as possible, your
forest structure should follow the organizational, administrative, and geographical structure of your organization.
Figure 2.2: Two forest s can allow user access bet ween it s domains by est ablishing explicit one-way t rust s.
Only t he domains connect ed by t he t rust s can allow access bet ween t he forest s.
Figure 2.3: The namespace of t he domain t ree shows t he hierarchical st ruct ure of t he t ree.
Explicit one-way trusts arent transitive. The one-way trusts in Win2K are the same as the one-way trusts that existed
in Windows NT. Creating one-way trusts among multiple forests or trees can be complicated, so its important to
keep it simple by limiting the domains that trust one another.
Det ermi ni ng t he Number of Trees
A tree is simply a grouping of domains. The domains that form a tree are arranged hierarchical and share a common
and contiguous namespace. Trees can be viewed one of two ways. The first view is the trust relationships among
domains. The second view is a view of the namespace of the domain trees as shown in Figure 2.3.
In a single forest in which all domains trust one another, the tree relationship is defined by the namespace that is
necessary to support the domain structure. For example, the root domain called company.com can have two
subdomains (or child domains) named seattle.company.com and chicago.company.com. The relationship between
the root domain and the two child domains is what forms the tree, or namespace.
In the previous section, I emphasized that multiple forests in an organization are generally not recommended.
However, this isnt to say that there arent situations in which multiple trees are appropriate or even recommended.
For one, multiple trees allow you to have multiple namespaces that coexist in a single directory. Multiple trees give
you additional levels of separation of the namespaces, something that domains dont provide. Although multiple
trees work well in most situations, I recommend that you start by creating one tree until the circumstances arise
that call for more.
You may be wondering if there are any extraordinary benefits to having multiple trees. For example, do multiple
trees reduce the replication or synchronization that occurs among domain servers? The answer is no because the
schema and configuration container are replicated to all domain controllers in the forest. In addition, the domain
partitions are only replicated among the domain controllers that are in the domain. Having multiple trees doesnt
reduce replication.
Likewise, you may be wondering whether multiple trees cause any problems. For example, does having multiple
trees require you to establish and maintain explicit one-way trust relationships? Again, the answer is no because the
transitive trust relationships are automatically set up among all domains in the forest. This includes all domains
that are in separate trees but in the same forest.
Desi gni ng t he Domai ns
The next task in planning AD is creating and designing the domains. A domain gives you a place to group users,
groups, computers, printers, servers, and other resources that belong together. In addition, a domain is a security
boundary for these objects, and it defines the set of information that is replicated among domain controllers. The
domain in AD works like the domain that exists in Windows NT.
A domain can also be called a partition, which is a physical piece of AD that contains the object information.
Figure 2.4 shows a domain structure with its contents of network resources.
The purpose of domains is to logically partition the AD database. Most large implementations of AD need to
divide the database into smaller pieces. Domains enable you to partition AD into smaller, more manageable units
that you can distribute across the network servers.
Domains are the basic building blocks of AD and Windows 2000. Domains can be connected to form the trees
and forests, and what connects them are the trust relationships, which are automatically established in AD. These
trusts allow the users of one domain to access the information contained in the other domains. When multiple
domains are connected by trust relationships and share a common schema, you have a domain tree. Every AD
installation consists of at least one domain tree.
Its your role as an administrator to decide the structure of domains and which objects, attributes, groups, and
computers are created. The design of a domain includes DNS naming, security policies, administrative rights, and
how replication is handled. When you design domains, follow these steps:
Determine the number of domains
Choose a forest root domain
Assign a DNS name to each domain
Partition the forest
Place the domain controllers for fault tolerance and high network availability
Determine the explicit trust relationships that need to be established, if any.
Figure 2.4: The domain st ruct ure is a piece of AD. It cont ains t he users, groups, comput ers, print ers, ser vers, and ot her resources.
Det ermi ni ng t he Number of Domai ns
I recommend that you start with one domain in your environment. This is true even if there are two or more physical
locations. This design keeps the layout of your domain simple and easy to maintain. You can then add other
domains as needed. The mistake some people make is to create a bunch of domains and not know what to do with
them. One domain will be adequate for most companies, especially smaller ones.
Although one domain will work in most circumstances, other circumstances necessitate having more than one
domain for an entire organization. Some of these are described below; you must decide which of these fit your
needs.
Admi ni st rat i ve Ri ght s
If your organization has multiple administrative groups that want guaranteed autonomy, you may need to
create additional domains and give each group its individual rights. For example, if two companies merge
together, one group may need to operate and maintain autonomous activities.
Int ernat i onal Set t i ng
If your organization is international, you may need to create additional domains to support another
languages. (Administrators, users, and others may need to access AD in their first language, and the schema
contains language-specific attribute display names.)
Repl i cat i on Traf fi c
Because the AD database can be distributed, you may want to create additional domains to hold the
distributed partitions. The need to create additional domains typically arises when you have a single
domain trying to replicate across wide area network (WAN) links. If the replication is too slow, you can
alleviate the problem by splitting the domain into two. You can then place the two domains on each side of
the WAN so that they can be closest to the users.
Account Securi t y Set t i ngs
Account security settings apply to the entire domain. Account security settings include password length and
expiration period, account lockup and intruder detection, and Kerberos ticket policy. These settings cannot
be changed in the domain for individual OUs or groups. If you need to have unique settings, you may
need to create another domain.
Preserve Exi st i ng Wi ndows NT Domai n
If your company already has an existing Windows NT domain, you may want to keep it instead of consoli
dating it into an AD domain. This requirement could produce more domains than planned.
Determining the number of domains for your organization is an individual effort. No one can tell you definitively
how many domains to have and how to split them without knowing more about your companys organization and
network. However, using these simple guidelines, you can establish parameters that enable you to effectively design
domains and determine the appropriate number for your company.
Choosi ng a Forest Root Domai n
The first domain that you create becomes the forest root domain (or root domain), which is the top of the forest.
The forest root domain is extremely important because it determines the beginning of the namespace and establishes
the forest. Because the AD forest is established with the first domain, you need to make sure that the name of the
root domain matches the top level in the namespace. For example, root domains are domains with names such as
company.com and enterprise.com. These domain names are the roots of the DNS structures and the root of AD.
Any subsequent domains you create or add to the tree form the tree hierarchy.
The first domain you create in an AD forest contains two forest-wide groups that are important to administering
the forest, the Enterprise Administrators group and the Schema Administrators group. Containing these two
groups makes the root domain special. You cannot move or re-create these groups in another domain. Likewise,
you cannot move, rename, or reinstall the root domain. In addition to these groups, the root domain contains the
configuration container, or naming context, which also includes the schema naming context.
After you install the root domain, I recommend that you back it up often and do everything you can to protect it.
For example, if all the servers holding a copy of the root domain are lost in a catastrophic event and none of them
can be restored, the root domain is permanently lost. This is because the permissions in the Enterprise
Administrator and Schema Administrator groups are also lost. There is no method for reinstalling or recovering the
root domain and its groups in the forest other than completely backing it up and restoring it.
Usi ng a Dedi cat ed Root Domai n
As I described above, the first domain you create in AD becomes the forest root domain. For smaller implementations
of AD, you may only need to create the root domain, nothing more.
For a larger implementation with multiple locations around the world, however, youll probably want to use a
dedicated root domain.
A dedicated root domain is a root domain that is kept small, with only a few user account objects. Keeping the
root domain small allows you to replicate it to other locations at low cost (that is, with little impact on network
usage and bandwidth). Figure 2.5 illustrates how you can replicate a dedicated root domain to the other locations
on your network.
For more informat ion on det ermining t he number of domains, see " Det ermining t he Number of Domains"
earlier in t his chapt er.
A dedicated root domain focuses on the overall operations, administration, and management of AD. There are at
least two advantages to using a dedicated root domain in a larger implementation of AD.
By keeping the user and printer objects out of the root domain, you enhance security by restricting access
to only a few administrators
By keeping the root domain small, you can replicate it to other domain controllers on the network. This
approach helps increase the availability of the network.
Because domain administrators can access and change the contents of the Enterprise Administrators and Schema
Administrators groups, having a dedicated root domain limits normal access. Membership in these built-in groups
should only be given to the enterprise administrators, and they should only access the domain when doing official
maintenance. In addition, membership in the Domain Administrators group of the root domain should be granted
only to the enterprise administrators. Taking these steps allows you to avoid any accidental changes to the root
domain. You should also create a regular user account for each of your administrators so that they dont carry
administrative privileges while doing regular work.
As I mentioned earlier in "Choosing a Forest Root Domain," always replicate the root domain to multiple servers
in an effort to provide fault tolerance for this domain. Because a dedicated root domain is small (no user or printer
objects), it can be replicated across the network more quickly and easily. In addition to replicating the root domain
across the local area network (LAN), you can replicate the root domain across the WAN to reduce the trust-traversal
traffic among trees.
Figure 2.5: A dedicat ed root domain is small enough t o ef ficient ly replicat e copies t o
t he ot her locat ions on your net work
Assi gni ng a DNS Name t o Each Domai n
After youve determined the number of domains and installed the root domain, you need to determine the DNS
names for each domain. DNS is a globally recognized, industry-standard system for naming computers and network
services that are organized in a hierarchy. AD clients make queries to DNS in an attempt to locate and log on to
domains and domain controllers.
Network users are better at remembering name-based addresses, such as www.company.com, than they are at
remembering number-based addresses, such as 124.177.212.34. DNS translates an easy-to-remember name address
(www.company.com) into a number address (124.177.212.34).
As Ive mentioned, the domain is identified by a DNS name. You use DNS to locate the physical domain controller
that holds the objects and attributes in the domain. DNS names are hierarchical (like AD domains). In fact, the
DNS name for a domain indicates the position of the domain in the hierarchy. For example, in the domain name
company.com, the DNS name tells us that the domain has to be at the top of the forest and is the root domain.
Another example is:
marketing.chicago.company.com
From this domain name, we know that the domain is the Marketing Departments domain in the Chicago location
of the company. The domain is two levels from the root domain, or top of the tree. The Chicago domain is a child
domain of the root domain, or company, and the Marketing domain is a child domain under Chicago.
When you create DNS names for the domains in AD, I recommend that you follow these guidelines:
Use an Internet-registered name for the top-level domain
Use Internet standard characters
Use locations to name child domains
Never use the same name twice.
Usi ng an Int ernet -Regi st ered Name for t he Top-Level Domai n
When you name your top-level domain, I recommend that you only use a DNS name that has been registered on
the Internet and is thus globally unique. For example, realtimepublishers.com is a top-level domain name and
should be registered with the Internet Corporation for Assigned Names and Numbers (ICANN). You dont need to
register the names of underlying domains because they fall under the control and jurisdiction of the top-level domain
owner/registrant. For example, the domain name research.realtimepublishers.com doesnt need to be registered.
Usi ng Int ernet St andard Charact ers
When you assign DNS names, youre restricted to using only Internet standard characters to ensure compatibility
with AD and the Internet. The basic standards for naming are as follows:
Domain names contain only letters, numbers, and hyphens (-)
Domain names cannot begin or end with a hyphen
The domain names of .com, .net, and .org cannot exceed 67 characters
Relative domain names (that is, the components between the dots in a fully qualified domain name) can
not exceed 22 characters (this doesnt include any extensions)
Domain names arent case sensitive
Domain names cannot include spaces.
Usi ng Locat i ons t o Name Chi l d Domai ns
When you determine the name of the child domains, I recommend that you use the geographical locations of your
company. This applies to the first layer of child domains that you create under the root domain. The key to designing
and naming this layer is the WAN layout: Try to match the domains to the locations in your companys WAN. For
example, the first layer of domains that you create under the root could have names based on physical locations.
Figure 2.6 portrays the first layer of domain names, representing the physical, or WAN, locations on your network.
I make this recommendation because other naming schemes based on business structures and organizations are
prone to constant change. In fact, I guarantee that theyll change and change many times. The AD domain hierarchy
isnt nearly as fluid or adaptable as the business itself. Once you create and name domains, you cannot move or
rename them easily. In addition, you cannot move or rename the root domain.
Using locations to name child domains is more flexible because physical locations on a network seldom change.
The organization at the specific site may change, but not the physical location itself. This design allows the tree to
be more flexible to everyday changes. However, if the physical location is changed or removed, the resources are
moved. This includes the physical resources, such as domain controllers, printers, and other equipment supporting
the site.
Figure 2.6: The first layer of domains direct ly under t he root domain is named aft er t he physical, or
WAN, locat ions on t he net work.
If your company is smaller and contained in one physical location, you could name domains after the company or
organization. These domains then hold all the objects and attributes for your company. This is an easy and efficient
design. However, if your company has multiple physical locations, with network resources spread across them,
youll want to create a second layer of domains (under the root domain) and give the domains location names. The
organizational structures of business units, divisions, and departments will then be placed under each of these
location domains.
Never Usi ng t he Same Name Twi ce
I recommend that you never use the same DNS name twice, even if the names are used on different networks. This
simple guideline will help eliminate any confusion down the road. For example, lets say you decide to use the
domain name engineering.company.com. Dont use this name for any other domain, even if the domain is on a
different network. A client may connect to both networks and query engineering.company.com. Depending on the
layout of the network, the client may locate the wrong domain in the wrong forest.
Di vi di ng t he Forest
In larger organizations, the implementation of AD can become quite large. As it grows, I recommend that you
break it into smaller pieces, known as partitions. By definition, a partition is a domain or portion of the directory
tree that extends from the beginning of a branch (or naming context) to the bottom of the tree. The domain
physically stores the containers, objects, and attributes in that branch. Several rules control creating partitions in
AD and how they operate.
The topmost partition is the root domain
Partitions dont overlap (one object cannot be held in two partitions)
The partitions contain all the information for the naming context.
In AD, the basic unit of partitioning is the domain. So when you create your first partition, youre actually creating
a child domain under the root domain. The domains in AD act as partitions in the database. This means that each
domain represents a partition in the overall AD database. Partitioning this database increases its scalability. As you
partition AD, you break it into smaller, more manageable pieces that can be distributed across the domain
controllers, or network servers. Figure 2.7 illustrates how you can divide the AD database into smaller pieces that
can be distributed to the domain controllers.
Breaking AD into smaller pieces and distributing them among multiple servers places a smaller load and less
overhead on any one server. This approach also allows you to control the amount and path of traffic generated to
replicate changes among servers. Once you create a partition, replication occurs among servers that hold copies.
In AD, you can create many partitions at multiple levels in the forest. In addition, copies of the domain can be
distributed to many different servers on the network. Although AD is distributed using partitions, any user can
access the information completely transparently. Users can access the entire AD database regardless of which server
holds which data. Of course, users must have been granted the proper permissions.
Although a single domain controller may not contain the entire AD database, users can still receive whatever
information they request. AD queries the global catalog on behalf of a user to identify the requested object, then
resolves the name to a server (domain controller) address using DNS. Again, this process is entirely transparent to
the user.
Pl aci ng t he Domai n Cont rol l ers f or Faul t Tol erance
After youve partitioned AD, you need to decide how to distribute each new domain or partition across the network
servers. The domain controllers are the servers that store the domains and their distributed copies. One domain
controller holds only one copy of an AD partition or domain unless its a global catalog. The domain controller
stores the objects for the domain or partition to which it belongs.
The availability of domain information is strictly determined by the availability of the domain controllers. Its
obvious that the domain controllers must be available so that users can log on and access AD information. For this
purpose, never have only one domain controller for any domain. I recommend that you have at least two domain
controllers for each domain to provide redundancy and fault tolerance for every domain in your organization.
Figure 2.7: You can par t it ion t he AD dat abase int o smaller pieces, t hen dist ribut e t hem among net -
work ser vers or domain cont rollers.
Det ermi ni ng Trust Rel at i onshi ps
Trust relationships are logical connections that combine two or more domains into one administrative unit. Trust
relationships allow permissions to be associated and passed from one domain to another. Without some sort of
trust among domains, users cannot communicate or share resources. In this section, Ill describe the advantages of
using bi-directional trusts, one-way trusts, and cross-link trusts.
Usi ng Bi -di rect i onal Transi t i ve Trust s
In AD, trust relationships are automatically established between every domain and its parent domain in the tree or
forest. This greatly reduces the overhead of managing trust relationships. The types of trusts that are created are
new in Win2K and are called bi-directional transitive trusts. The best way to understand the concept of transitive
trusts is to use an example. Figure 2.8 shows bi-directional trusts being established among all the domains and their
child domains.
Figure 2.8: Each domain has a bi-direct ional t ransit ive t rust relat ionship bet ween it self and each of it s
child domains.
One of the advantages of these new trusts is that theyre automatically established among all domains; this allows
each domain to trust all the other domains in the forest. Another advantage is that these bi-directional trusts,
which are
automatically established using Win2Ks Kerberos security mechanism, are much easier to set up and administer
than Windows NTstyle trusts. Having bi-directional trusts also reduces the total number of trust relationships
needed in a tree or forest. For example, if you tried to accomplish the same thing in NT, youd have to create two-
ways trusts between one domain and every other domain. This would increase the total number of trusts exponen-
tially with the number of domains.
If you have experience with Windows NT domains, you may know something of trust relationships. However, the
trusts in AD differ from NT trusts because theyre transitive. To help you understand what this means, Ill provide
an example. Win2K transitive trusts work much like a transitive equation in mathematics. A basic mathematical
transitive equation reads as follows:
A=B, B=C, therefore A=C
When applying this transitive concept to trust relationships, you get an understanding of how transitive trusts work
among domains. For example, if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A trusts
Domain C. Figure 2.9 illustrates this idea. Transitive trust relationships have been set up between Domain A and
Domain B and between Domain B and Domain C. Thus, Domain A trusts Domain C implicitly.
Figure 2.9: A domain t ree viewed in t erms of it s t ransit ive t rust relat ionships. Because t ransit ive
t rust relat ionships have been set up bet ween Domain A and Domain B and bet ween Domain B
and Domain C, Domain A t rust s Domain C implicit ly.
In Windows NT, trusts were non-transitive, so they didnt allow this implicit trust to exist. For one domain to trust
another domain, an explicit trust relationship had to be created between them.
When domains are created in an AD forest, bi-directional trust relationships are automatically established. Because
the trust is transitive and bi-directional, no additional trust relationships are required. The result is that every domain
in the forest trusts every other domain. Transitive trusts greatly reduce your overhead and the need to manually
configure the trusts. Because trusts are automatically set up, users have access to all resources in the forest as long as
they have the proper permissions.
Transitive trusts are a feature of the Kerberos authentication protocol. The protocol is used by AD and provides
distributed authentication and authorization. The parent-child relationship among domains is only a naming and
trust relationship. This means that the trust honors the authentication of the trusted domain. However, having all
administrative rights in a parent domain doesnt automatically make you an administrator of a child domain.
Policies set in a parent dont automatically apply to child domains because the trust is in place.
Usi ng One-Way Trust s
One-way trusts arent transitive and are used among domains that arent part of the same forest. If youre familiar
with the one-way trusts in Windows NT, the one-way trusts that exist in Win2K are just the same. However,
theyre only used in a handful of situations.
First, one-way trusts are often used when new trust relationships must be established among domains of different
forests. You can use them among domains to isolate permissions. For example, you can use one-way trusts to allow
access among forests and among the domains of the same tree. Figure 2.10 shows how you can create a one-way
trust between two domains in two different forests. Setting up a one-way trust allows users to access network
resources in the direction of the trust. The actual user rights depend on the access control lists (ACLs) governing
the domains.
Figure 2.10: A one-way t rust is est ablished bet ween a domain in Forest 1 and a domain in Forest
2. The t rust allows access t o net work resources in each domain.
The second use of one-way trusts is to create a relationship from an AD domain to backward-compatible domains,
such as Windows NT. Because Windows NT domains cannot naturally participate in AD transitive trusts, you
must establish a one-way trust to them. You have to manage one-way trusts manually, so try to limit the number
you use.
In both these situations, you can create two one-way trusts among the domains. However, two one-way trusts dont
equal a bi-directional transitive trust in AD.
Usi ng Cross-Li nk Trust s
Cross-link trusts are used to increase performance among domains. Cross-link trust relationships help increase the
speed at which users authenticate among domains. However, cross-link trusts are only needed between two
domains that are both far from the root domain. To completely understand the need for the cross-link trusts, you
first need to understand how user authentication works in AD.
When a user needs to authenticate to a resource that doesnt reside on its own domain, the client first has to
determine where the resource is and locate it. If the resource isnt in the local domain, the domain controller will
pass back a referral list of other domain controllers that might have the resource. The workstation then contacts the
appropriate servers in the referral list to find the resource. This process continues until the requested resource is
found. This process is often referred to as chasing referrals and can take time, especially on large or complex AD
networks.
Walking up and down the domain tree branches lengthens the time it takes to query each domain controller and
respond to the user. To speed this process up, you can establish a cross-link, or shortcut, trust relationship between
two domains. If you decide to use a cross-link trust, I recommend that you place it between the two domains that
are farthest from the root domain.
For example, suppose you have a domain tree that has domains 1, 2, 3, 4, and 5 in one branch and domains 1, A,
B, C, and D in another branch. Domains 5 and D are located farthest from the root domain. Lets say that a user
in Domain 5 needs to access a resource in Domain D. To accomplish this request, the authentication process must
traverse up the first branch and down the second branch while talking to each domain controller. Continuous
authentications like this create a significant amount of network traffic. To alleviate this problem, you can establish a
cross-link between Domain 5 and Domain D. Figure 2.11 illustrates the layout of the domain tree with the cross-link
established between the two domains.
Figure 2.11: The domain t ree has t wo branches, Domains 1, 2, 3, 4, and 5 are one branch, and domains 1, A, B, C, and D
are t he second branch. The cross-link t rust is est ablished bet ween domains 5 and D.
The cross-link that has been established serves as an authentication bridge between the two domains. The result is a
better authentication performance between the domains.
Desi gni ng Organi zat i onal Uni t s f or Each Domai n
An OU is a container object that allows you to organize your objects and tie a Group Policy Object (GPO) to it.
Using the OU, you can group similar objects into logical structures in a domain. OUs can also be nested to build a
hierarchy in a domain. This hierarchy of containers is typically named after divisions, departments, and groups in
your company. When youre designing and creating the hierarchical structure in each domain, its important to
understand the following characteristics of OUs:
OUs can be nest ed
An OU can contain other OUs, enabling you to build a hierarchy inside each domain.
OUs can hel p del egat e admi ni st rat i on
You can delegate administrative tasks to subordinate administrators by creating subordinate OUs. Using
nested OUs, you can fine-tune the level of control you need.
OUs aren t securi t y pri nci pal s
You cannot make an OU a member of a group. You cannot grant users permissions to resources because
they reside in a particular OU. Because OUs are used to delegate administration, they can specify who
manages the resources in the OUs, but they dont indicate the resources a user can access.
OUs can be associ at ed wi t h a GPO
A GPO enables you to define configurations for users and computers in OUs. For example, you can create
a desktop policy that every user in the OU will use.
OUs don t need t o be vi ewed by users
It isnt necessary for you to design OUs with user navigation in mind. Although users can view the OU
structure, it isnt an efficient method for finding resources. The preferred method for users to find resources
is by querying the global catalog.
Now that you understand a few of the basic characteristics for OUs, you need to consider the following guidelines
for designing an efficient and effective OU structure:
Create OUs to delegate administration
Create OUs to reflect your companys organization
Create OUs for Group Policy
Create OUs to restrict access.
Creat i ng OUs t o Del egat e Admi ni st rat i on
Ive mentioned that OUs can be used to create administrative areas in a domain. Using OUs, you can delegate
administrative tasks to subordinate administrators. For example, suppose the Engineering Department wants to
administer its own objects and resources in the Chicago domain. You can accomplish this by creating the following OU:
engineering.chicago.company.com
After youve created the new OU and placed all the objects and resources in it, you can grant explicit permissions
to the administrators of the Engineering Department so that they can control their own objects. Figure 2.12
illustrates how you can create the Engineering OU in the Chicago domain.
Another nice feature that I mentioned earlier (see "Designing Organizational Units for Each Domain") is that OUs
can be nested. This enables you to build a hierarchy in each domain. For example, lets say the Testing Group in
the Engineering Department wants full administrative control over all its resources, such as users, printers, and
computers. To accommodate this request, you simply create a new OU directly under the Engineering OU in the
Chicago domain. The hierarchical structure now looks like the following:
testing.engineering.chicago.company.com
After youve created the new OU and placed the resources, you can give full privileges to the Testing groups
administrator. If an OU is nested, it inherits the properties of the parent OU by default. For example, if the
Engineering OU has certain security or Group Policy objects set, theyre passed down to the Testing OU. The
Testing OU is considered nested under the Engineering OU.
Be careful to limit the number of OU layers you create. Creating too many layers can increase the administrative
overhead. Limiting the number of OU layers also increases user logon performance. When a user logs on to AD,
the security policies take effect. To find all these policies, the workstation must search all layers of the OU structure.
Having fewer OU layers allows the client to complete this search more quickly.
Creat i ng OUs t o Ref l ect Your Company s Organi zat i on
If you dont create OUs in your domain, all users, printers, servers, computers, and other resources are displayed in
a single list. This type of layout makes it difficult to search for resources. This problem increases as the number of
objects in the domain grows.
Figure 2.12: You can creat e t he Engineering OU in t he Chicago domain, t hen assign permissions
o t he Engineering Depar t ment administ rat ors t o manage all t he object s.
One of the many benefits of creating OUs in a domain is the organization of this flat layout. OUs allow you to
create an organization that reflects your companys divisions, departments, and groups. In fact, you can use your
companys organizational chart or a similar document to help you. Figure 2.13 illustrates how you can create OUs
based on an organizational chart.
Figure 2.13:OUs have been creat ed in a domain based on an organizat ional char t .
Creat i ng OUs f or Group Pol i cy
Group Policy enables you to define Win2K desktop configurations for users and computers. Desktop configurations
have settings that govern and control the users experience at the workstation. GPOs can also be associated with an
OU. This association allows all users and computers in the OU and any nested OUs to receive the settings defined
in Group Policy. These settings configure a number of items, including installed software, Registry settings, and
logon scriptsjust to name a few.
For more informat ion on Group Policy, I recommend t hat you check out anot her free eBook from
Realt imepublishers: The Definit ive Guide t o Windows 2000 Group Policy by Darren Mar-Elia, a link t o
which can be found at ht t p:/ / www.realt imepublishers.com.
The ability to set Group Policy on OUs allows you to control a large set of users and computers from a central
point. If you have a special need for certain users and computers, you can create an OU and establish Group
Policy. For example, if the Accounting Department needs specific settings on its desktops, you can create an
OU=Accounting and establish the specific policy. Group Policy will then apply to every user and computer in the
new OU.
As I mentioned above, GPOs can be associated with OUs as well as the domain and site objects in AD. Because
GPOs can be associated with each of these objects, you can create implementations using GPOs to generate various
combinations. If you arent careful, these combinations can become very complicated and cause you headaches.
Creat i ng OUs t o Rest ri ct Access
The quickest and easiest way to restrict total access to network resources is to create a new OU and place the
network resources in it. You can then restrict access to the OU, thereby removing access to the network resources.
In addition, the objects representing the network resources are no longer visible.
Users who dont have the right to read an object, can normally still see it in AD. This may be a problem if you have
highly secure network resources that you dont want anyone else to see. You can restrict and hide the resources by
creating a new OU in the domain and limiting access to only the few who need it.
Desi gni ng t he Si t es f or t he Forest
Sites are locations on the physical network that contain AD servers. A site is stored in AD as an object and is
defined as one or more well-connected TCP/IP subnets. By "well-connected," I mean that the network connectivity
among the subnets is highly reliable and supports a data-transfer rate of at least 10 megabits per second.
Designing sites and site links in AD takes advantage of the physical network layout. (For an explanation of site
links, see "Creating Sites and Site Links Based on Network Topology" below.) The basic assumption is that servers
and workstations with the same subnet address are connected to the same network segment and have LAN speeds.
Defining a site as a set of subnets allows administrators to easily configure AD access and replication topology to
take advantage of the physical network. Sites also help you locate network servers so that theyre physically close to
the users who depend on them.
Its your role as an administrator to design the site objects and site links for your tree or forest that assure the best
network performance. Its also your job to determine what speed assures this performance and reduces server
downtime as a result of network outages. Establish site objects and site links based on network and subnet speed.
While many subnets can belong to a single site, a single subnet cant span multiple physical sites. To help you
establish a design for the sites in your forest, you need to consider the following guidelines:
Create sites and site links based on network topology
Use sites to determine the placement of domain controllers
Use sites to determine the placement of global catalog servers.
Creat i ng Si t es and Si t e Li nks Based on Net work Topol ogy
When you create sites and site links for your tree or forest, use the physical layout of your network, or topology.
Before you can properly create sites and site links, you need a solid understanding of what they are.
About Si t es
Sites are groups of computers (or subnets) that share high-speed-bandwidth connections on one or more TCP/IP
subnets. Subnets are groups of local segments on the network that are physically located in the same place.
Multiple site objects create a site topology. Figure 2.14 portrays a site with TCP/IP subnets that exist between the
servers and workstations. A LAN always connects a site.
Figure 2.14: A sit e is one or more TCP/ IP subnet s or LAN net works t hat exist bet ween t he ser vers and workst at ions.
One domain can span more t han one sit e, and one sit e can cont ain mult iple domains. However, for design
purposes, it s impor tant to remember that sites define how replication occurs among domain controllers and
which domain controller a user s workstation contacts for initial authentication. Normally, the workstation first
t ries t o cont act domain cont rollers in it s sit e.
About Si t e Li nks
Site links are objects that represent the WAN links on your network. They also represent any low-bandwidth
connections between two locations. Site links connect two or more sites together. They help you determine the
replication schedule and latency, and they help you determine where to place network servers. The rule is to create
a site link when a connection is slower than LAN-speed connection. Defining site links allows administrators to
configure AD and replication to take advantage of the network.
The site link object has four settings.
Cost
Helps the replication process determine the path of the communication among domain controllers
Repl i cat i on Schedul e
Determines what time of day the replication process can execute
Repl i cat i on Int erval
Helps the replication process determine how often to poll the domain controllers on the other side of the link
Transpor t
Helps the replication process determine which transport protocol to use during communications.
Site and site link objects are stored in a special container called the configuration container. The configuration
container is stored and replicated to every AD domain controller, providing each server with complete details of
the physical network topology. A change to any of the information in the site or site link objects causes replication
to every domain controller in the forest.
Creat i ng t he Si t e Topol ogy
Sites and site links create the site topology, as shown in Figure 2.15. The site topology helps the replication process
determine the path, cost, and protocol among domain controllers.
Figure 2.15: The sit e t opology is creat ed from t he sit e object s and t he sit e links. The sit e t opology helps t he replicat ion process
det ermine t he pat h, cost , and prot ocol among domain cont rollers.
When you create the site topology, its useful to have a complete set of physical LAN and WAN maps. If your
company has campus networks at one or more locations, youll need to have the physical maps of those locations.
These maps should include all the physical connections, media or frame types, protocols, and speed of connections.
When defining the sites, begin by creating a site for every LAN or set of LANs that are connected by high-speed
bandwidth connections. If there are multiple physical locations, create a site for each location that has a LAN
subnet. For each site that you create, keep track of the IP subnets and addresses that comprise the site. Youll need
this information when you add the site information to AD.
Sit e names are regist ered in DNS by t he domain locat or, so t hey must be legal DNS names. You must also
use Int ernet st andard charact erslet t ers, numbers, and hyphens. (For more informat ion, see " Using
Int ernet St andard Charact ers" earlier in t his chapt er.)
After youve created the sites, you need to connect them with site links to truly reflect the physical connectivity of
your network. To do this, you need to first assign each site link a name. Site links are transitive, just like trust
relationships in Win2K. This means that if Site A is connected to Site B and Site B is connected to Site C, its
assumed that Site A can communicate with Site C.
The process of generating this site topology is automatic, and its handled by a special Win2K service called the
Knowledge Consistency Checker (KCC). If you dont like the topology that the KCC generates for you, you can
create it manually.
The purpose of creating the site topology is to ensure rapid data communications among AD servers. The site
topology is used primarily when setting up replication of AD. However, the placement of the domain controllers
and partitions govern when and how replication takes place.
Usi ng Si t es t o Det ermi ne t he Pl acement of Domai n Cont rol l ers
After youve properly created site and site link objects, you can use them to help you decide how to properly
distribute AD partitions across the network servers. Network servers are the domain controllers that store AD
domains and their copies. One domain controller holds only one copy of an AD partition or domain. The server
works to authenticate users and provide responses to queries about the objects and attributes.
Your responsibility is to determine where to place the domain controllers on the network to best suit the needs of
the users. I recommend that they be located on or near the users subnet or site. When a workstation connects to
the network, it typically receives a TCP/IP address from DHCP. This TCP/IP address identifies the subnet or site
to which the workstation is attached. If the workstation has a statically assigned IP address, itll also have statically
configured subnet information.
In either case, when users log on to the network, their workstations can reach the closest domain controller site by
knowing the assigned address and subnet information. Because computers in the same site are physically close to
each other in, communication among them is reliable and fast. Workstations can easily determine the local site at
logon because they already know what TCP/IP subnet theyre on, and subnets translate directly to AD sites.
If no domain controller is available in the local site, user traffic will cross the WAN links and sites to find other
servers. To place the domain controller for best overall connectivity, select the site where the largest numbers of
users are located. All the users in that site will authenticate to the local domain controller. This approach guarantees
that the users will retrieve their object information from the global catalog partition. The location of the server is
important because users are required to access a global catalog server when they log on.
Usi ng Si t es t o Det ermi ne t he Pl acement of DNS Servers
Ive already mentioned that DNS and AD are inseparably connected. AD uses DNS to locate the domain
controllers. The DNS service enables users workstations to find the IP addresses of the domain controllers. The
DNS server is the authoritative source for the locator records of the domains and domain controllers on the network.
To find a particular domain controller, the workstation queries DNS for the appropriate service (SRV) and address
(A) resource records. These records from DNS provide the names and IP addresses of the domain controller.
The availability of DNS directly affects the availability of AD and its servers. As mentioned, users rely on DNS as a
service. To guarantee DNS as a service, I recommend that you place or have available at least one DNS server for
every site on your network. This allows all users to access the DNS service locally. You dont want users to have to
query DNS servers that are offsite to locate the domain controllers that are on their own subnet.
The AD domain cont rollers quer y DNS t o find each ot her during replicat ion. A new domain cont roller
par t icipat es in replicat ion by regist ering it s locat or records wit h DNS. Likewise, each domain cont roller must
be able t o look up t hese records. This is t he case even if t he domain cont rollers are on t he same subnet .
If you depend on an outside DNS service, you may need to adjust the number of DNS servers and physical placement,
if possible. Youll also need to verify that the outside DNS service supports the required SRV resource record. If it
doesnt, you may need to install and configure your own implementation of Microsofts DNS to support AD.
If you dont want to depend on an existing DNS service or a DNS service that is offsite, you may want to install
the Microsoft DNS service that is integrated into AD. The Microsoft DNS service stores the locator records for the
domain and domain controllers in AD. You can then have one or more domain controllers provide the DNS service.
Again, I recommend that you place at least one DNS server for each site object in your environment. Using the
Microsoft DNS service is an optional configuration, and storing the locator records in AD may have a negative
impact on replication traffic on large networks.
Summary
My first recommendation for troubleshooting AD was to make sure that its components are designed and
implemented correctly. In addition, the efficiency of AD depends on the design and implementation of key structures
forests, trees, domains, and OUs. I also recommended that the sites and site links be properly established to
support the distribution and replication of the system. I also discussed the placement of other supporting servers,
such as domain controllers, global catalog servers, and DNS servers. The design and implementation of these
structures is strictly your responsibility as network administrators. Before you can effectively troubleshoot AD, make
sure you feel confident about your design.
Chapt er 3
Moni t ori ng and Tuni ng t he Wi ndows 2000 Syst em and Net work
A Windows 2000 (Win2K) network is a system of devices that work together toward a common goal of providing
communication among users, servers, and applications. The most important of these devices are Win2K domain
controllers. This book is primarily interested in the components or software that are required for Win2K Active
Directory (AD) services. In this chapter, Ill focus on how you can monitor Win2K domain controllers and their
subsystems to help you reduce downtime and improve AD performance.
Moni t ori ng Wi ndows 2000 Domai n Cont rol l ers
As previously mentioned, domain controllers are the single most important type of device on an AD-based Win2K
network. These devices share the responsibility of storing the directory information, and they interact with each
other to replicate the directory information and keep it up to date. In addition, domain controllers are responsible
for authenticating user logons and servicing other requests for access to directory and network resources. Because
domain controllers are crucial to the performance and operation of the directory, its critical that you continually
monitor these servers. A poorly performing or misbehaving domain controller can easily cause network downtime
and loss of directory functionality. For example, when the directory slows down significantly or is unavailable, users
cant log on, there is no Address Book for Exchange, and users cant print or access Web-based applications.
When you consider how youll monitor your domain controllers, first remember that no one domain controller
contains all of the directory information. In any well-built Win2K network, each domain partition in the directory
typically has two or more domain controllers hosting the domain to provide fault tolerance for directory services.
With this kind of redundancy in place, you might initially be fooled into thinking that monitoring each domain
controller for performance and downtime isnt all that important.
However, each domain controller plays a role in supporting your users. For example, if two domain controllers in
the same directory partition are placed in separated sites or subnets, users in each site will use the domain controller
nearest them. However, if one of the domain controllers goes down, users in that location must traverse the wide
area network (WAN) to log on and access the directory. This is usually undesirable, especially if there are too many
users and/or if the WAN link is slow.
Another example of why you need to monitor domain controllers is that some domain controllers on a Win2K
network (no matter how many domain controllers it may have) are unique. For example, some Win2K domain
controllers perform special duties called Flexible Single-Master Operation (FSMO) roles. Although the replication
of AD is multimaster, the FSMO roles held by these domain controllers are single-master (much like a Windows
NT 4.0 primary domain controller, or PDC). This essentially means that these domain controllers dont have
additional copies or replicas to provide fault tolerance if the domain controller hosting a particular role is down.
As I discussed in Chapter 1, these FSMO domain controllers perform special roles for AD, such as managing the
domain, managing the schema, and supporting down-level clients. If any of these critical domain controllers go
down, the directory loses functionality and can no longer update or extend the schema, or add or remove a domain
from the directory.
Failing to monitor domain controllers can adversely affect a networks performance and availability. For example, if
an entire department is unable to access the domain controller or directory, users lose time, and the company loses
money. To help you ensure that your domain controllers are available, you can, and should, monitor and analyze
Win2K in the five following areas:
Overall system
Memory and cache
Processor and thread
Disk
Network.
Ill discuss each of these areas, and the reason for their importance, in the following sections. Ill discuss monitoring
AD itself in Chapter 4.
Moni t ori ng t he Overal l Syst em
Monitoring a Win2K domain controller means watching the operation of both the servers operating system (OS)
and its hardware subsystems. When you monitor domain controllers, I recommend that you begin by establishing a
performance and reliability baseline for eachthat is, a nominal and acceptable level of operation under real-world
conditions on your network. Establishing a baseline allows you to track the operation of the domain controller over
time. If a potential problem or bottleneck occurs, you can recognize it immediately it because you can compare
that behavior to the baseline established for that domain controller.
Monitoring domain controllers means watching for problems or bottlenecks in the OS and its subsystems. A simple
example of a bottleneck occurs when a domain controllers processor is running at 100 percent usage because one
application has tied up the central processing unit (CPU). Almost every NT/Win2K administrator has seen this
occur at some point or another.
Win2K provides several utilities that can assist you in monitoring your domain controllers and their subsystems.
These tools provide features that will help you search for bottlenecks and other problems. Theyre described below.
Task Manager
Gives you a quick view of which applications and processes are running on the domain controllers. This
utility allows you to view a summary of the overall CPU and memory usage for each of these processes and
threads.
Per formance consol e
Allows you to view the current activity on the domain controller and select the performance information
that you want collected and logged. You can customize Win2Ks performance-counter features and architec
ture to allow applications to add their own metrics in the form of objects and counters, which you can then
monitor using the Performance console. By default, the Performance console has two applications, System
Monitor and Performance Logs and Alerts.
System Monitor enables you to monitor nearly every aspect of a domain controllers performance and estab
lish a baseline for the performance of your domain controllers. Using System Monitor, you can see the per
formance counters graphically logged and set alerts against them. The alerts will appear in Event Viewer.
Performance Logs and Alerts enable you to collect information for those times when you cant detect a
problem in real time. Performance Logs and Alerts allows you to collect domain controller performance
data for as long as you wantdays, weeks, or even months.
Event Vi ewer
Allows you to view the event logs that gather information about a domain controller and its subsystems.
There are three types of logs: the application log, the system log, and the security log. Although the event
logs start automatically when you start the domain controller, you must start Event Viewer manually.
When monit oring domain cont rollers using t he Per formance console s logging feat ure, make sure you don t
act ually creat e a problem by filling t he comput er s disk wit h large log files.
First , be sure t o only include t hose st at ist ics in t he logging process t hat you absolut ely need. Keep t he
sampling period t o t he minimum required t o evaluat e domain cont roller per formance and usage. To select
an appropriat e int er val for your comput er, est ablish a baseline of per formance and usage. Also, t ake int o
account t he amount of free disk space on your domain cont roller when you begin t he logging process.
Finally, make sure t hat you have some applicat ion in place (such as t he Per formance console) t hat cont inu-
ally monit ors t he domain cont roller t o ensure t hat it has plent y of free disk space.
In addit ion t o monit oring t he local domain cont roller, you can use t he Per formance console t o monit or
domain cont rollers remot ely and st ore t he log files on a shared net work drive. This enables you t o monit or
all t he domain cont rollers in a direct or y from one console or ut ilit y.
At the heart of the Performance console and Task Manager are the performance counters that are built into the
Win2K OS. Ill introduce each of these monitoring utilities briefly in the upcoming sections and demonstrate how
they can help you monitor specific subsystems. Keep in mind that this chapter isnt intended to be an in-depth
study of all the capabilities of these utilities. Instead, my intention is to provide a general introduction to them and
show you how you can use them to assist you in monitoring your domain controllers.
Usi ng Task Manager
The easiest and quickest way to view how each application or system process is using the CPU and memory is by
using Win2Ks Task Manager. This utility allows you to see which processes or threads are running on a Win2K
domain controller at any given moment; it also shows a summary of overall CPU and memory usage. To launch
Task Manager, either right-click the taskbar (typically at the bottom of the screen) and choose Task Manager or
press Ctrl+Alt+Del, then click Task List from the menu. Figure 3.1 shows an example of Task Manager.
Task Manager supplies three pages of information: Applications, Processes, and Performance. Each of these pages
will help you understand more about a domain controllers processes and memory. Ill discuss each of these screens
in greater detail later in this chapter.
Usi ng t he Per formance Consol e
In Win2K, one of the main utilities for monitoring a domain controller is the Performance console. The Performance
console allows you to view the current activity on the domain controller and select the performance information
that you want collected and logged.
Figure 3.1: Win2K s Task Manager allows you t o view and manage t he applicat ions
and processes running on a domain cont roller and manage t heir per formance.
In Windows NT, t he Per formance console was known as Per formance Monit or, and like most NT administ rat ion
ut ilit ies, it was a st andalone ut ilit y rat her t han an MMC snap-in.
The Performance console helps you accurately pinpoint many of the performance problems or bottlenecks in your
system. It monitors your Win2K domain controller by capturing the selected performance counters that relate to
the system hardware and software. The performance counters are programmed by the developer of the related sys-
tem. The hardware-related counters typically monitor the number of times a device has been accessed. For example,
the physical disk counters indicate the number of physical disk reads or writes and how fast they were completed.
Software counters monitor activity related to application software running on the domain controller. To launch the
Performance console, choose Start>Programs>Administrative Tools>Performance.
The first application that starts in the Performance console is System Monitor. Using System Monitor, you can
view the current activity on the domain controller and select information to be collected and logged for analysis.
You can also measure the performance of your own domain controller as well as that of other domain controllers
on your network. System Monitor is shown in Figure 3.2.
Figure 3.2: The Per formance console includes bot h Syst em Monit or and Per formance Logs and Aler t s.
When it starts up, System Monitor isnt monitoring any counters or performance indicators for the system. You
determine which counters System Monitor tracks and displays. To add a counter, click the Plus (+) tool on the
toolbar or right-click anywhere in the System Monitor display area and choose Add Counters from the shortcut
menu. Using either approach, the Add Counters dialog box appears, as shown in Figure 3.3, where you can choose
which counters to monitor.
Once you choose the counter that you want to view, System Monitor tracks its performance in real time. When you
first start using System Monitor, the number of counters that are available seems overwhelming because there are
counters for almost every aspect of the computer. However, in the spirit of the age-old 80/20 rule, youll probably
find that you tend to use about 20 percent of the available counters 80 percent of the time (or more), using the
other counters only when you need specific monitoring or troubleshooting information.
Figure 3.3: In Syst em Monit or, you can choose which count ers you want t o
t rack and monit or on t he display.
If you don t underst and t he meaning of a par t icular Per formance console count er, highlight it and click Explain.
The informat ional dialog box t hat appears provides a descript ion of t he select ed count er (and, in some cases,
what t he various values or ranges might indicat e).
In later sections of this chapter, Ill discuss how you can use System Monitor to monitor memory, view processes,
and monitor network components on a domain controller as well as monitor the disk subsystem.
Event Vi ewer
As with its NT predecessor, Win2K uses an event logging system to track the activity of each computer and its
subsystems. The events that are logged by the system are predetermined and tracked by the OS. In addition,
Win2K provides Event Viewer, which allows you to view the events that have been logged.
Event s Tracked i n Event Logs
Win2K domain controllers occasionally encounter serious error conditions and halt operation. This situation is
called a stop error (also informally known to some users as the "blue screen of death," or BSOD). The error message
is displayed on a solid blue background on a domain controllers console. A number of stop errors are worthwhile
monitoring because they affect the reliability of a computer. Fortunately, stop errors are recorded in a domain
controllers Event Log when the computer restarts. To view the stop errors in the Event Log, you need to launch
Event Viewer.
In addition to stop errors, if a Win2K domain controller restarts, these events are also recorded in the system log
section of the Event Log. The reasons for a restart could include OS crashes, OS upgrades, and hardware maintenance.
Another type of event that a domain controller tracks in the Event Log is application crashes. Win2K uses the Dr.
Watson utility (Drwtsn32.exe) to record problems and failures in applications running on the domain controller.
Failures are recorded in the application log section of the Event Log. Again, you can use Event Viewer and the
information in the Event Log to analyze problems with an application.
Types of Event Logs
When you use Event Viewer, the Event Log is separated into three logs, as follows:
Appl i cat i on Log
Contains events logged by applications or programs such as Exchange or Microsoft Internet Information
Server (IIS) that are running on the computer. The developer of an application decides which events to
record.
Syst em Log
Contains events logged by the subsystems and components of the domain controller. For example, if a disk
driver has problems or fails, it records the events in the system log. You can use this log to determine the
general availability and uptime of the domain controller.
Securi t y Log
Records security events, such as when a user successfully logs on or attempts to log on. This log also records
events that relate to file access. For example, an event is recorded when a file is created, opened, or deleted.
By default, the security log can only be seen by system administrators.
St ar t i ng Event Vi ewer
The event logs start automatically when you start the domain controller; you must start Event Viewer manually. To
start or display Event Viewer, choose Start>Run, type eventvwr, then click OK, or choose
Start>Programs>Administrative Tools>Event Viewer. Event Viewer starts and displays the following screen (see
Figure 3.4).
Types of Event s Logged by Event Vi ewer
Event Viewer logs several types of events, each of which has a different severity to help you analyze a problem. The
types of events are as follows:
Error
Signifies that a severe problem has occurred. This means that data was lost or functionality was lost. For
example, if a service fails to load during startup or stops abruptly, an error is logged.
Warni ng
Less significant than an error and indicates that a problem could occur in the future. For example, a warn
ing is logged if disk space becomes too low.
Informat i on
Describes important situations that need noting. This event is typically used to notify when an operation is
successfulfor example, a disk driver loaded successfully and without errors.
Success audi t
Logs successful access to a secured system resource such as a file or directory object. A success audit event is
a successful security-access attempt. For example, if a user attempts to log on to the system and is success
ful, a success audit event is logged.
Figure 3.4: The st ar t up screen or display for Event Viewer.
Only a user wit h administ rat ive privileges can view t he securit y log. Regular users can only view t he applicat ion
and syst em logs.
Fai l ure audi t
Is the opposite of the success audit event. For example, if a user attempts to log on to the system or access a
secured resource and fails, a failure audit is logged.
Sor t i ng and Fi l t eri ng Event s
Using Event Viewer, you can sort events on the screen so that you can easily review and analyze the information.
To sort events on the screen, choose View>Newest First (the default) or Oldest First.
In addition to selecting the sort order for events, you can filter them. Filtering events allows you to select and view
only the events that you want to analyze. To set a filter for events in Event Viewer, choose View>Filter Events.
Figure 3.5 illustrates the dialog box that appears to help you specify the filter characteristics.
Figure 3.5: Event s can be filt ered in Event Viewer t o rest rict t he list of event s t hat are displayed.
Expor t i ng Event s
In addition to sorting and filtering events in Event Viewer, you can export events in a variety of formats to use with
applications such as Microsoft Excel. To export events, choose Action>Export List. When the Save As dialog box
appears (shown in Figure 3.6), you can type a file name with the .xls extension, or choose a file type, such as Text
(Comma Delimited) (*.csv).
Moni t ori ng Memory and Cache
One of the most common performance problems with Win2K domain controllers (and all servers, for that matter)
is excessive paging, which is caused by insufficient random access memory (RAM). In this situation, one of the
greatest performance gains you can achieve is adding more physical RAM to a system. Therefore, I recommend
that the first subsystem you monitor be the domain controllers memory and cache. Problems caused by lack of
memory can often appear to be problems in other parts of the system. For instance, a lack of memory can cause
insufficient file system cache, which can lead to and be seen as a performance problem in the disk subsystem.
Before I give you the details of monitoring your domain controllers memory, Ill first briefly introduce the memory
model for Win2K. Memory in Win2K provides a page-based virtual memory management scheme (called Virtual
Memory Manager, or VMM) that allows applications to address 4 gigabytes (GB) of memory. Memory in Win2K
is able to do exactly that by implementing virtual addresses. Each application is able to reference a physical chunk
of memory, at a specific virtual address, throughout its life. VMM takes care of whether the memory should be
moved to a new location or swapped to disk completely independently of the application.
Because everything in the system is realized using pages of physical memory, its easy to see that pages of memory
become scarce rather quickly. VMM uses the hard disk to store unneeded pages of memory in one or more files called
paging files. Paging files represent pages of data that arent currently being used but may be needed spontaneously
at any time. By swapping pages to and from paging files, VMM is able to make pages of memory available to
applications on demand and provide much more virtual memory than the available physical memory.
One of the first monitoring or troubleshooting tasks youll carry out is to verify that your domain controller has
enough physical memory. Table 3.1 shows the minimum memory requirements for a Win2K domain controller.
Figure 3.6: The event s in Event Viewer can be expor t ed for use wit h various applicat ions.
Thi s
Minimum Installation
Server running a basic set of services
Server running an expanded set of services
Requi res t hi s amount of memory
64 MB
128 MB
512 MB
Table 3.1: Minimum memor y requirement s for a Win2K domain cont roller.
These recommendations are minimum physical memory requirements. Your physical memory requirements for
actual production servers will typically be much higher. Because your Win2K domain controllers will at least be
running AD, I recommend that you always start with at least 512 megabytes (MB) RAM. If you want to load other
applications that come with their own memory requirements, youll need to add memory to support them. If there
isnt enough memory on your domain controller, it will start running slower as it pages information to and from its
hard drive. When physical memory becomes full and an application needs access to information not currently in
memory, VMM moves some pages from physical memory to a storage area on the hard drive called a paging file.
As the domain controller pages information to and from the paging file, the application must wait. The wait occurs
because the hard drive is significantly slower than physical RAM. This paging also slows down other system activities
such as CPU and disk operations. As I mentioned earlier, problems caused by lack of memory often appear to be
problems in other parts of the system. To maximize the performance and availability of your domain controller servers,
its important for you to understand and try to reduce or eliminate wherever possible the performance overhead
associated with paging operations.
Fortunately, there are a couple of utilities that you can use to track memory usage. Two of the most common are
utilities Ive already introduced: Task Manager and the Performance console.
Usi ng Task Manager t o Vi ew Memory on a Domai n Cont rol l er
You can use Task Manager to view memory usage on a domain controller. To do so, click the Performance tab.
Figure 3.7 shows an example of the Performance page in Task Manager running on Win2K.
The Performance page in Task Manager contains eight informational panes. The first two are CPU Usage and
CPU Usage History. These two panes and the Totals pane all deal with usage on the CPU, or processor. The
remaining panes can be used to analyze the memory usage for the domain controller and include the following:
MEM Usage
A bar graph that shows the amount of virtual memory your domain controller is currently using. This pane
is one of the most useful because it can indicate when VMM is paging memory too often and thrashing.
Thrashing occurs when the OS spends more time managing virtual memory than it does executing applica
tion code. If this situation arises, you need to increase the amount of memory on the system to improve
performance.
Memory Usage Hi st ory
A line graph that tracks the size of virtual memory over time. The history for this pane is only displayed in
the line graph and not recorded anywhere. You can use this information to help determine if there is a
problem with virtual memory over a longer period of time.
Physi cal Memory
Tells you the total amount of RAM in kilobytes (K) that has been installed on your domain controller. This
pane also shows the amount of memory that is available for processes and the amount of memory used for
system cache. The amount of available memory will never go to zero because the OS will swap data to the
hard drive as the memory fills up. The system cache is the amount of memory used for file cache on the
domain controller.
Figure 3.7: The Per formance page of Win2K s Task Manager allows you t o view a
domain cont roller s memor y usage.
Commi t Charge
Shows three numbers, which all deal with virtual memory on the domain controller: Total, Limit, and
Peak. The numbers are shown in kilobytes K. Total shows the current amount of virtual memory in use.
(Youll notice that this number matches the number shown in MEM Usage.) Limit is the maximum possi
ble size of virtual memory. (This is also referred to as the paging limit.) Peak is the highest amount of
memory that has been used since the domain controller was started.
Kernel Memory
Shows you the total amount of paged and non-paged memory, in kilobytes, used by the kernel of the OS.
The kernel provides core OS services such as memory management and task scheduling.
I mentioned that you can easily and quickly check the memory usage on your domain controller using Task
Manager. Task Manager allows you to see the amount of virtual memory in use.
Usi ng t he Per formance Consol e t o Moni t or Memory on a Domai n Cont rol l er
In addition to using Task Manager, you can use the Performance console to determine whether the current amount
of memory on a domain controller is sufficient. The System Monitor application in the Performance console allows
you to graphically display memory counters over time. I also recommend that you display the memory cache counters.
Avai l abl e Memory Count ers
To determine if there is a bottleneck in memory, you need to check three memory counters:
Available Bytes (under the Memory object in System Monitor)
Available Kbytes (kilobytes or KB)
Available Mbytes (megabytes or MB).
You can use any of these three counters to understand your domain controllers memory commitment. I recommend
that you reserve at least 20 percent of available memory for peak use.
To view one or all of the available memory counters, either click the Plus (+) tool on the toolbar or right-click any-
where in the display area and choose Add Counters from the shortcut menu. Once the Add Counters dialog box
appears, choose Performance Object>Memory, then choose one of the available memory counters. Figure 3.8 shows
the Available Bytes counter of the memory Performance Object.
The Available Bytes counter shows the amount of physical memory available to processes running on the domain
controller. This counter displays the last observed value only; it isnt an average. Its calculated by summing space
on three memory lists.
Free
Memory that is ready or available for use.
Zeroed
Pages of memory filled with zeros to prevent later processes from seeing data used by a previous process.
St andby
Memory removed from the working set of a process and en route to disk, but still available to be recalled.
If Available Bytes is constantly decreasing over a period of time and no new applications are loaded, it indicates
that the amount of working memory is growing, or it could signal a memory leak in one or more of the running
applications. A memory leak is a situation where applications or processes consume memory but dont release it
properly. To determine the culprit, monitor each application or process individually to see if the amount of memory
it uses constantly increases. Whichever application or process constantly increases memory without decreasing it is
probably the culprit.
Page-Faul t Count ers
When a process or thread requests data on a page in memory that is no longer there, a domain controller issues a
page fault. Here, the page has typically been moved out of memory to provide memory for other processes. If the
requested page is in another part of memory, the page fault is a soft page fault. However, if the page has to be
retrieved from disk, a hard page fault has occurred. Most domain controllers can handle large numbers of soft page
faults, but hard page faults can cause significant delays.
Figure 3.8: Using t he Available Byt es memor y count er t o monit or or t rack how much memor y is left for
users or applicat ions.
Page-fault counters help you determine the impact of virtual memory and page faults on a domain controller.
These counters can be important performance indicators because they measure how VMM handles memory.
Page Faul t s/ sec
Indicates the number of page faults without making a distinction between soft page faults and hard page faults.
Page Reads/ sec
Indicates the number of times the disk was read to resolve hard page faults. This counter indicates the
impact of hard page faults.
Pages Input / sec
Indicates the number of pages read from disk to resolve hard page faults. This counter also indicates the
impact of hard page faults.
Figure 3.9 illustrates how you can use System Monitor to track page-fault counters.
Figure 3.9: The Page Fault s/ sec, Page Reads/ sec, and Pages Input / sec count ers det ermine t he impact of
vir t ual memor y and paging.
If the numbers recorded by these counters are low, your domain controller is responding quickly to memory requests.
However, if the numbers are high and remain consistently high, its time to add more RAM to the domain controller.
Pagi ng Fi l e Usage
Another important set of counters helps you determine the size of virtual memory. These counters are related to
paging file usage. Before I discuss how you can effectively use these counters, its important that you better understand
the paging file and its function. The paging file is the space on a domain controller that enables the OS to swap
out memory to the hard drive. As the domain controller loads more applications than it can run in actual memory,
it pages some memory to the hard drive to create room for the new applications.
You can see how much the paging file is being used by watching two counters under the Paging File object.
% Usage
Indicates the current usage value that was last recorded.
% Usage Peak
Indicates the high-water mark for the paging file.
If a domain controller was perfect, the OS would have enough memory for every application that was loaded and
would never page memory out. Both the % Usage counter and the % Usage Peak counter would be at zero. The
opposite is that the domain controller is paging memory as fast as possible, and the usage counters are high. An
example of a bad situation is one in which your domain controller has 128MB of memory, the % Usage Peak
counter is at 80 percent, and the % Usage counter is above 70 percent. In this situation, its fairly certain that your
domain controller will be performing poorly.
By default, Win2K automatically creates a paging file on the system drive during installation. Win2K bases the size
of the paging file on the amount of physical memory present on the domain controller (in most cases, its between
768MB and 1536MB). In addition to this paging file, I recommend that you create a paging file on each logical
drive in the domain controller. In fact, I recommend that you stripe the paging file across multiple physical hard
drives, if possible. Striping the paging file improves performance of both the file and virtual memory because
simultaneous disk access can occur on multiple drives simultaneously.
The recommendation for using disk striping on the paging file works best with Small Computer System Inter face
(SCSI) drives rather than those based on Integrated Device Electronics (IDE) inter faces. This is because SCSI
handles multiple device contention more ef ficiently than IDE and tends to use less CPU power in the process.
Also, I don t recommend that you spread the paging file across multiple logical drive volumes (par titions) located
on the same physical drive. This won t generally aid paging file per formanceand it may actually hinder it.
To change or set the virtual memory setting on your domain controller, right-click My Computer, then choose
Properties from the shortcut menu. In the System Properties dialog box, click the Advanced tab, then click
Performance Options. Notice that the Performance Options dialog box allows you to see the current setting for
Virtual Memory. Next, click Change to display more information and to change the paging file settings.
Changing t he paging file size or locat ion is unfor t unat ely one of t hose rare set t ing changes in Win2K t hat
requires you t o rest ar t t he domain cont roller before t he change t akes ef fect . So, if you decide t o change any
set t ings for t he paging file, do it during a scheduled maint enance t ime when it s safe t o t ake t he domain
cont roller down and doing so won t af fect your users.
Syst em Cache
In addition to tracking the amount of memory and virtual memory in the domain controller, you need to keep an
eye on the computers system cache settings. The system cache is an area in memory dedicated to files and appli-
cations that have been accessed on the domain controller. The system cache is also used to speed both file system
and network input/output (I/O). For example, when a user program requests a page of a file or application, the
domain controller first looks to see if its in memory (system cache). Thats because a page in cache responds more
quickly to user requests. If the requested information isnt in cache, the OS fulfills the user request by reading the
file page from disk.
If the system cache isnt large enough, bottlenecks will occur on your domain controller. The Cache object in
System Monitor and its counters help you understand caching in Win2K. In addition, several counters under the
Memory object help you determine the amount of file cache. Two of the counters that best illustrate how the file
cache is responding to requests are described below.
Copy Read Hi t s %
A counter under the Cache object that tracks the percentage of cache-copy read requests that are satisfied
by the cache. The requests dont require a disk read to give the application access to the page. A copy read is
a file-read operation that is satisfied by a memory copy from a page in the cache to the applications buffer.
Cache Faul t s/ sec
A counter under the Memory object that tracks the number of faults that occur when a page sought in the
system cache isnt found. The page must be retrieved from elsewhere in memory (a soft fault) or from the
hard drive (a hard fault).
When you re considering using t he Copy Read Hit s % count er t o assess file-cache per formance, you might
also consider t racking t he Copy Reads/ sec count er, which measures t he t ot al number of Copy Read operat ions
per second. By assessing t hese numbers t oget her, you ll have a bet t er sense of t he significance of t he dat a
provided by the Copy Reads Hits % counter. For example, if it were to spike momentarily without a corresponding
jump (or perhaps even a decrease) in t he number for overall Copy Reads/ sec, t he dat a might not mean much.
Ideally, you can ident ify a cache bot t leneck when t here is a st eady decrease in t he Copy Read Hit s % count er
wit h a relat ively flat Copy Reads/ sec figure. A st eady increase in bot h count ers, or an increase in Copy Read
Hit s % and a relat ively flat Copy Reads/ sec, indicat es good file cache per formance.
Thus, the Copy Read Hits % counter records the percentage of successful file-system cache hits, and the Cache
Faults/sec counter tracks the number of file-system cache misses. Figure 3.10 shows these counters in System
Monitor. Remember that one of the counters is a percentage and the other is a raw number, so they wont exactly
mirror each other.
Generally speaking, I recommend that a domain controller have at least an 80 percent cache hit rate over time. If
these two counters show that your domain controller has a low percentage of cache hits and a high number of
cache faults (misses), you may want to increase the total amount of RAM. Increasing the RAM allows the domain
controller to allocate more memory for system cache and should increase the cache hit rate.
Moni t ori ng Processors and Threads
I find that many people mistakenly believe that monitoring a domain controller is focused primarily on the domain
controllers physical processor(s), or CPUs. However, the truth is that the processor doesnt do anything unless there
are processes and threads to run. In Win2K, a process is made up of one or more threads that run on the CPU. A
bottleneck at the processor typically means that either one or more processes are consuming most of the processor
time or there are too many threads contending for the CPU.
A process is an executable program that follows a sequence of steps. Each process requires a cycle from the domain
controllers processor as it runs. A thread is the component of a process that is being executed at any time. Thus, a
process must contain at least one thread before it can perform an operation. A single process executing more than
one thread is referred to as being multithreaded. Win2K is a multithreaded OS that is capable of running multiple
processor threads simultaneouslyeven, when theyre present, across multiple CPUs.
Figure 3:10: The Copy Read Hit s % and t he Cache Fault s/ sec count ers show how t he domain
cont roller s cache is responding.
When an application is developed, the developer determines the number of threads each process will use. In a
single-threaded process, only one thread is executed at one time. In a multithreaded process, more than one thread
can be executed concurrently. Being multithreaded allows a process to accomplish many tasks at the same time and
avoid unnecessary delay caused by thread wait time. To change threads, the OS uses a process called context
switching, which interrupts one thread, saves its information, then loads and runs another thread.
In addition to the multithreaded and multitasking approach to handling processes and threads, Win2K allows pri-
orities to be assigned to each process and thread. The kernel of the Win2K OS controls access to the processor
using priority levels.
Usi ng Process Vi ewer t o Moni t or Processes and Threads
Every Win2K domain controller comes with the Process Viewer utility (Pviewer.exe). This utility is part of the
Win2K Support Tools, which is located in the Support folder on the Win2K CD. Process Viewer is a great tool for
looking at the various processes and associated threads currently running on your domain controller. To launch
Process Viewer on your computer, choose Start>Programs>Accessories>Command Prompt, then type pviewer.
Figure 3.11 shows an example of Process Viewer.
Figure 3.11: The Process Viewer ut ilit y allows you t o view t he processes and t hreads
running on your domain cont roller.
Using this utility, you can view the name of each process, the amount of time its been running, the memory allocated
to it, and its priority. You can also view each thread that makes up a selected process. For each thread, you can see
how long its been running, its priority, context switches, and starting memory address.
In addition to the information you see on the main screen, you can display the memory details for a process. Figure
3.12 illustrates the Memory Details dialog box that is shown when you select a process, then click Memory Details.
Figure 3.12: Memor y det ails for each process are displayed by clicking Memor y Det ails in
Process Viewer s main window.
When using Process Viewer, you can st op or kill a process t hat is running on a domain cont roller by select ing
it and clicking Kill Process. However, be sure you underst and t he funct ion and impact of killing a process
before doing soit may be vit al t o your domain cont roller s funct ionalit y. Worse yet , by killing a process, you
can irrecoverably lose or corrupt t he dat a.
Usi ng Task Manager t o Vi ew Processes on a Domai n Cont rol l er
Earlier in this chapter (see "Using Task Manager to View Memory on a Domain Controller"), I described using Task
Manager as the quickest and easiest method of monitoring the performance of the CPU. You can also use Task
Manager to see which processes or threads are running on the Win2K domain controller and to view a summary of
overall processor or CPU usage. To launch Task Manager, either right-click the taskbar and choose Task Manager
or press Ctrl+Alt+Del, then select Task List from the menu. Then click the Processes tab. A list is displayed of the
processes currently running on the domain controller. Figure 3.13 shows an example of the processes running on
Win2K and displayed in Task Manager.
This view provides a list of the processes that are runningtheir names, their process identifiers (PIDs), the per-
centage of CPU processing theyre taking up, the amount of CPU time theyre using, and the amount of memory
theyre using. Notice the System Idle Process, which always seems to be toward the top of the process list. This is a
special process that runs when the domain controller isnt doing anything else. You can use the System Idle Process
to tell how the CPU isnt loaded because its the exact opposite of the CPU Usage value on the Performance tab.
For example, if the CPU Usage value is 5, the System Idle Process value will be 95. A high value for the System
Idle Process means that the domain controller isnt heavily loaded, at least at the moment you checked.
Worki ng wi t h t he Li st of Processes
You can sort this list of processes according to one of the column labels mentioned above. For example, if you want
to view the processes in order of the amount of memory used, simply click that columns label. The display or list
will change accordingly.
Task Manager also allows you to customize the columns, thereby receiving additional information about the
processes and being able to assess as many as 23 parameters. To customize the columns, on the Processes page,
choose View>Select Columns. As shown in Figure 3.14, notice that many additional columns of information can
be displayed. These additional columns will help you monitor and tune each process more completely. For more
information about each of the additional columns, refer to the Help menu in Task Manager.
Figure 3.13: Win2K s Task Manager allows you t o view and manage processes t hat are
current ly running on t he syst em.
In addition, you can see which of these processes belong to an application. To do so, click the Applications tab,
right-click one of the applications on the Applications page, then click Go To Process. This will take you to the
associated applications process on the Process tab. This feature helps you associate applications with their processes.
Figure 3.14: The Select Columns dialog box in Task Manager allows you t o monit or addit ional
impor t ant st at ist ics about t he processes t hat are running on your domain cont roller.
As you may know, highlight ing a process in Task Manager, t hen clicking End Process, st ops t hat process from
running. This is a useful feat ure because it allows you t o st op processes t hat don t provide any ot her means
of being st opped. However, I recommend t hat you only use t his met hod as a last resor t because t he process
st ops immediat ely and doesn t have a chance t o clean up it s resources. Using t his met hod t o st op processes
may leave domain controller resources unusable until you restar t. It may also cause data to be lost or corrupted.
Vi ewi ng Informat i on about Processes
If you view the list of processes from either Process Viewer or Task Manager and dont know what a process is, you
can use the Computer Management utility to view the processes and their associated file paths or locations.
Computer Management also lets you view the version, size, and date of the application or module for each process.
To view the Computer Management utility, choose Start>Programs>Administrative Tools>Computer Management.
Once the utility has loaded, select System Tools, System Information, Software Environment, Running Tasks.
Figure 3.15 displays processes and their associated information in the Computer Management utility.
Usi ng t he Per formance Consol e t o Vi ew Processes on a Domai n Cont rol l er
You can use the System Monitor application in the Performance console to view the values of the performance
counters for the processor, processes, and threads. This utility allows you to graphically display these counters over
time. In the next few sections, Ill discuss some of the counters and how you can use them.
% Processor Ti me Count er
The first counter that you should check when monitoring the domain controller is % Processor Time. This counter
gauges the activity of the computers CPU. It shows the percentage of time that all processors in the domain controller
are busy executing code other than the System Idle Process. Acceptable processor activity ranges between 1 percent
and 85 percent, although the actual amount depends on the type of applications loaded on your domain controller.
The % Processor Time counter is a primary indicator of processor activity. This counter is calculated by measuring
the time that the processor spends executing the idle process, then subtracting that value from 100 percent. It can
be viewed as the percentage of useful work that the processor executes. To view the % Processor Time counter, you
use System Monitor. Figure 3.16 shows the % Processor Time counter in System Monitor.
Figure 3.15: The Comput er Management ut ilit y allows you t o view t he processes t hat are running on your domain
cont roller as well as t he pat h and file name informat ion associat ed wit h each process.
If the % Processor Time counter is consistently high, there may be a bottleneck on the CPU. I recommend that
this counter consistently stay below 85 percent. If it pushes above that, you need to find the process that is using a
high percentage of the processor. If there is no obvious CPU "hog," you may want to consider adding another
processor to the domain controller or reducing that domain controllers workload. Reducing the workload might
involve stopping services, moving databases, removing directory services, and so on.
Int errupt s/ sec Count er
The Interrupts/sec counter measures the rate of service requests from the domain controllers I/O devices. This
counter is the average number of hardware interrupts that the processor is receiving and servicing each second. If
this value increases without an associated increase in system response, there could be hardware problems on one of
the I/O devices. For example, a network interface card installed in the domain controller could go bad and cause
an excessive amount of hardware interrupts. To fix the problem, you need to replace the offending network cards
driver or the physical card.
The Interrupts/sec count doesnt include deferred procedure calls; theyre counted separately. Instead, this counter
tracks the activity of hardware devices that generate interrupts, such as the system clock, mouse, keyboard, disk
drivers, network interface cards, and other peripheral devices. (For example, the system clock interrupts the CPU
every 10 milliseconds.) When an interrupt occurs, it suspends the normal thread execution until the CPU has
serviced the interrupt.
During normal operation of the domain controller, there will be hundreds or thousands of interrupts per second.
System Monitor displays the counter as a percentage of the real number. This means that if the domain controller
has 560 interrupts in one second, the value is shown as 5.6 on the graph. Figure 3.17 displays the Interrupts/sec
counter using System Monitor.
Figure 3.16: The % Processor Time count er give you t he abilit y t o view t he amount of t ime t hat t he proces-
sor is doing real work.
Unfortunately, its difficult to suggest a definite threshold for this counter because this number depends on the
particular processor type in use and the exact role and use of the domain controller. I therefore recommend that
you establish your own baseline for this counter and use it as a comparison over time. This will help you know
when a hardware problem occurs. For example, a network interface card installed in the domain controller could
go bad and cause an excessive number of hardware interrupts. By having an established baseline, you can quickly
identify that there is a problem.
Processor Queue Lengt h Count er
The Processor Queue Length counter under the System object displays the number of processes or threads waiting
to be executed in the run queue that is shared among all processors on the server. This counter displays the last
observed value only; its not an average. If there are too many threads waiting for the CPU and the CPU cannot
keep up, the system is processor-bound and starts to slow down. Figure 3.18 illustrates how System Monitor shows
Processor Queue Length.
Figure 3.17: The Int errupt s/ sec count er allows you t o view t he impact t he hardware I/ O devices have on
t he per formance of t he domain cont roller.
In System Monitor, you can make changes to the graph display. To do this, right-click anywhere on the graph, then
choose Proper ties from the shor tcut menu. The System Monitor Proper ties dialog box appears, containing several
tabs to change the display and ef fect of the graph and data. For example, if you want to change the graph scale,
click the Graph tab and change the Ver tical Scale parameters. To confirm the change, click Apply, then OK.
I recommend that your domain controller not have a sustained Processor Queue Length of greater than two
threads. If the number of threads goes above two, performance slows down, as does responsiveness to the users. The
domain controller shown in the figure could be in trouble, especially if this type of activity is sustained. There are
several ways to alleviate the domain controller slowing down. You can replace the CPU with a faster processor, add
more processors, and reduce the workload. In some situations, the Processor Queue Length counter will increase if
the system is paging heavily, so adding memory or RAM could be needed. To determine if you need more RAM,
monitor the paging counters.
Moni t ori ng t he Di sk
Because the hard drives in the domain controller have moving parts, theyre always the slowest subsystem in the
computer. In fact, the hard drive subsystem will typically be over 100,000 times slower than the memory subsystem.
As a result, the architects of Win2K designed the file-system caching service. Its sole responsibility is to move data
off the hard drives and into the faster memory subsystem. This minimizes the performance penalty of retrieving
data from the domain controller.
By nature, a hard drive is massive and cheap. The disk subsystem can contain hundreds of GB storing millions or
billions of files. In turn, memory is relative small and expensive. Therefore, the architects of Win2K designed the
virtual memory system to store pieces of memory on the hard drive, thereby allowing more room for users and
applications. However, as I discussed earlier (see "Paging File Usage"), you pay a performance price for paging.
Figure 3.18: The Processor Queue Lengt h count er indicat es how congest ed t he processor is.
Usi ng t he Per formance Consol e t o Moni t or t he Di sk Subsyst em
Because system performance depends so heavily on the disk subsystem, its important that you understand how to
monitor it. To properly monitor the disk subsystem, you need to monitor disk usage and response time, which
includes the number of actual reads and writes plus the speed with which the disk accomplishes each request. The
primary utility you use to monitor these attributes is System Monitor in the Performance console. Using System
Monitor, you can view key counters that apply to physical device usage and the logical volumes on the drives.
% Di sk Ti me and % Idl e Ti me Count ers
The % Disk Time counter under the PhysicalDisk object allows you to view how busy the domain controllers hard
drive is. This counter is a percentage of elapsed time that the hard drive is busy servicing read and write requests.
The % Idle Time counter under the PhysicalDisk object reports the percentage of time the hard drive is sitting idle.
Using these counters, you can monitor the physical activity of the hard drives in each computer. Figure 3.19
illustrates the % Disk Time and % Idle Time counters in System Monitor.
Figure 3.19: The % Disk Time count er allows you t o view how busy a physical disk drive is, and t he % Idle
Time count er t racks t he percent age of t ime a drive is idle.
The figure shows that as you might expect, % Disk Time and % Idle Time basically mirror each other. I recommend
that if the value for % Disk Time is consistently above 70 percent, you consider reorganizing the domain controller
to reduce the load. However, if the domain controller is a database server, the threshold can go as high as 90 percent.
The threshold value depends on the type of server that has been implemented and what has caused the disk I/O.
For example, if VMM is paging heavily, it can drive up the % Disk Time counter. The simplest solution here is to
add memory.
Di sk Reads/ sec and Di sk Wri t es/ sec Count ers
In addition to the percentage of time the disk is busy, you can also see what the disk is doing. You can monitor this
using two counters under the PhysicalDisk object in System Monitor.
Di sk Reads/ sec count er
Tracks the rate of read operations on the disk.
Di sk Wri t es/ sec count er
Tracks the rate of write operations on the disk.
Normally, a domain controller will perform twice as many (if not more) read operations than write operations; it
can also service a read request at least twice as fast. This is because the write request has to write the data, then verify
that it was written. You can see the Disk Reads/sec and Disk Writes/sec counters in System Monitor, as shown in
Figure 3.20.
Figure 3.20: The Disk Reads/ sec and t he Disk Writ es/ sec count ers show how t he domain cont roller is
handling t he disk request s t hat come t o it .
Using these counters, watch for spikes in the number of disk reads when your domain controller is busy. If you
have the appropriate amount of memory on your domain controller, most read requests will be serviced from the
system cache instead of hitting the disk drive and causing disk reads. You want at least an 80 percent cache hit rate;
this means that only 20 percent of read requests are forced to the disk. This is valid unless you have an application
that reads a lot of varying data at the same timefor example, a database server is by nature disk-intensive and
reads varying data. Obtaining a high number of cache hits with a database server may not be possible.
Current Di sk Queue Lengt h Count er
The Current Disk Queue Length counter represents the number of requests outstanding on the disk at any one
time. The disk has a queue, or list, that can hold the read and write requests in order until they can be serviced by
the physical device. This counter shows the number of requests in service at the time the sample is taken. Most
disk devices installed on your domain controller are single-spindle disk drives. However, disk devices with multiple
spindles, such as some Redundant Array of Independent Disks (RAID) disk systems, can have multiple reads and
writes active at one time. Thus, a multiple-spindle disk drive can handle twice the rate of requests of a normal device.
Figure 3.21 displays System Monitor tracking the length of the disk queue.
Figure 3.21: The Current Disk Queue Lengt h count er represent s t he number of out st anding read and writ e
request s. Using t his count er, you can monit or t he per formance of t he queue for t he disk drives.
If the disk drive is under a sustained load, this counter will likely be consistently high. In this case, the read and
write requests will experience delays proportional to the length of this queue, divided by the number of spindles on
the disks. For decent performance, I recommend that the value of the counter average less than 2.
Because gat hering disk count ers can cause a modest increase in disk-access t ime, Win2K doesn t
aut omat ically act ivat e all t he disk count ers when it st ar t s up. By default , t he physical disk count ers are on,
and t he logical disk count ers are of f. The physical disk count ers monit or t he disk driver and how it relat es t o
t he physical device. The logical disk count ers monit or t he informat ion for t he par t it ions and volumes t hat have
been est ablished on t he physical disk drives.
% Free Space Count er
An example of a logical disk counter is the % Free Space counter. This counter is the percentage of the free space
available on the logical disk or volume. Free space is calculated as a ratio of the total usable space provided on the
volume of the logical disk drive. This counter is obviously an important one to monitor because it allows you to
view the amount of disk space that is left for user and application requests.
This counter allows you to monitor the performance of the disk drives as they start to fill up. This task is important
because as a disk drive starts to run out of space, each write request becomes tougher to perform and slows down
overall disk performance. The reason for this is that as the drive fills up, each write takes longer to search for space.
The longer it takes the disk to write the data, the less it does, so performance slows. Thus, as the drive fills up, it
works harder to service requests; this is often called thrashing. I recommend that you always leave at least 10 percent
of the disk free to minimize thrashing.
Moni t ori ng t he Net work
Each Win2K domain controller depends on the network to move information to its users and to other servers.
However, if the network becomes too crowded and traffic exceeds capacity, performance for all users and domain
controllers will suffer. You need to monitor the network components for each domain controller on your network
to help eliminate bottlenecks. Monitoring the network typically consists of observing usage on network components
and measuring the amount of traffic on the network.
Usi ng Net work Moni t or t o Wat ch Net work Traf fi c
Network Monitor (Netmon.exe) allows you to analyze in-depth, low-level network traffic and enables you to detect
and analyze problems on your local networks and WAN connections. Network Monitor captures and displays the
network packets that the Win2K domain controller receives from users and other servers to provide real-time traffic
monitoring and analysis. You can also display the traffic in a post-capture mode to help you analyze it after the fact.
In real-time mode, Network Monitor allows you to monitor and test network traffic for a specific set of conditions.
If the conditions are detected, it displays the events and prompts you for the appropriate action. In post-capture
analysis, network traffic is saved in a proprietary capture file and can be parsed by protocol to pick out specific
network frame types.
Network Monitor does the following:
Captures network data in real-time or delayed mode
Provides filtering capabilities when capturing network packets
Uses parsers for detailed post-capture analysis.
To st ar t t he domain cont roller wit h t he logical disk count ers on, you use t he DISKPERF ut ilit y. At t he command
prompt , t ype DISKPERF YV. This set s t he domain cont roller t o gat her count ers for bot h t he logical disk
devices and t he physical devices t he next t ime t he syst em is st ar t ed. For more informat ion about using t he
DISKPERF ut ilit y, t ype DISKPERF / ? at t he command prompt .
Usi ng t he Per formance Consol e t o Moni t or Net work Component s on a Domai n Cont rol l er
You can use System Monitor in the Performance console to monitor the domain controllers network performance.
Specific performance counters allow you to watch the computers network throughput and network interfaces.
Domai n Cont rol l er Net work Throughput
The easiest way to measure domain controller throughput and the bandwidth of each network component is to
determine the rate at which the computer sends and receives network data. Several performance counters under the
Server object in System Monitor can help you measure the data transmitted through your domain controllers network
components. These counters represent all the network traffic sent to and received from the domain controller and
all the network interface cards installed on it.
Byt es Tot al / sec
The number of bytes the domain controller has sent and received from the network each second. This value
provides an overall indication of how busy the domain controller is, servicing network requests. It can help
you determine whether any network components are creating bottlenecks for network traffic.
Byt es Transmi t t ed/ sec
The number of bytes that the domain controller has sent on the network. It indicates the network traffic
that has been sent.
Byt es Recei ved/ sec
The number of bytes that the domain controller has received from the network. It indicates the network
traffic that has been received.
The advantage of the last two counters is that they break out the values for traffic sent and received.
I recommend that once youve monitored these counters, you compare the results to your domain controllers total
network throughput. To do this, I suggest that you establish a baseline of data rates and averages. Establishing a
baseline allows you to know what to expect from the domain controller. If a potential problem or bottleneck in
network throughput occurs, you can recognize it immediately because you can compare it against the baseline
youve established.
You can also make some estimates as to where a bottleneck exists if you know the network and bus speeds of the
domain controller. If the data rate through the card is approaching the network limit, segmenting and adding a
card may help. If the aggregate data rate is approaching the bus speed, it may be time to split the load for the
domain controller and add another one or go to clustering.
Net work Int er face Throughput
If you want to break down the amount of traffic to each individual network adapter or interface card, youll want
to use the Network Interface object in System Monitor. The counters that display the amount of traffic processed
by each network interface card are Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec. The counters in the
Net work Monit or is a complex t ool t hat allows you t o monit or all kinds of net work t raf fic and t roubleshoot a
variet y of net work problems. Thus, a det ailed explanat ion of it is beyond t he scope of t his chapt er and book.
previous section have similar names, but they display the amount of traffic for the entire domain controller, regardless
of the actual number of interface cards installed. Using the counters assigned to each network adapter allows you to
drill down and see how each performs individually.
Byt es Tot al / sec
The number of bytes the network interface card has sent and received from the network each second. This
value measures the rate at which bytes are both sent and received on the network interface card; this
includes all frame and media types. This value also provides an overall indication of how busy the network
adapter is.
Byt es Sent / sec
The rate at which bytes are sent on the network interface. This value breaks down the amount of traffic
being sent.
Byt es Recei ved/ sec
The rate at which bytes are received. This value breaks down the amount of traffic being received.
Figure 3.22 illustrates how you can use the Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec counters in
System Monitor to monitor the domain controllers network adapter.
Figure 3.22: The Byt es Tot al/ sec, Byt es Sent / sec, and Byt es Received/ sec count ers allow you t o monit or
t he domain cont roller s net work adapt er.
Summary
As a network administrator, a critical part of your job is making sure that each and every domain controller hosting
AD is functioning properly. To accomplish this task, you need to properly monitor each of these Win2K domain
controllers; this in turn means watching over the critical OS components and hardware subsystems. To help you
monitor a domain controller and its subsystems, Win2K provides several utilities, and this chapter discussed the
most important ones: Task Manager, the Performance console, and Event Viewer. Using these utilities, you can
watch server resources and subsystems in real time while they work to support the requests by users, applications,
and other servers.
int ernat ional copyright and t rademark laws. No mat erial (including but not limit ed t o t he t ext , images, audio, and/ or video)
may be copied, reproduced, republished, uploaded, post ed, t ransmit t ed, or dist ribut ed in any way, except t hat one copy
may be downloaded for your personal, non-commercial use on a single comput er. In connect ion wit h such use, you may
not modify or obscure any copyright or ot her propriet ar y not ice. If you have any quest ions about t hese t erms, or if you
would like informat ion about licensing mat erials from Realt imepublishers.com, please cont act us via e-mail at info@real-
t imepublishers.com
Chapt er 4
Moni t ori ng Act i ve Di rect ory
Troubleshooting Active Directory (AD) and AD-based networks requires that you become familiar with AD constructs
as well as monitoring tools and techniques. Monitoring AD allows you to determine whether problems are occurring in
any part of the directory. However, its sometimes difficult to accurately determine the cause of a problem because AD is
distributed across domain controllers and interacts with a number of external services and protocols, such as:
Domain Name System (DNS)for name resolution
Lightweight Directory Access Protocol (LDAP)for directory lookups
Transmission Control Protocol/Internet Protocol (TCP/IP)for transport.
AD also has a complex infrastructure containing many different components. To ensure the health of the directory
as a system, you must monitor all of these components. You also need to understand ADs internal processes, such
as replication.
In this chapter, Ill describe which infrastructure components you need to continually monitor to ensure AD
availability as well as some of the built-in and third-party utilities that are available to help you do so. Its always a
good idea to have a sound understanding of ones tools before using them, so Ill start by introducing the tools in
our monitoring tool set.
Usi ng t he Moni t ori ng Tool s
You can use several tools to monitor the individual areas of AD and AD as a service or system. These tools include
built-in Win2K utilities and Support Tools/Resource Kit utilities as well as those available from third-party
independent software vendors (ISVs). This chapter will give you an overview of all of these utilities and describe
how they can help you monitor the directory. It wont give a comprehensive list of all utilities built into Windows
2000 (Win2K) or available on the market, and it wont provide extensive documentation on any of these tools.
Rather, itll focus on tools that represent, in my opinion, the best of the built-in and third-party tools.
Thi rd-Par t y Tool s
In this section, Ill discuss NetPros DirectoryAnalyzer and NetIQs AppManager.
Di rect oryAnal yzer from Net Pro
DirectoryAnalyzer from NetPro was one of the first AD monitoring tools on the market, and it performs real-time
monitoring and alerting on all aspects of the AD infrastructure. Instead of monitoring individual domain controllers,
it monitors the directory as a whole. It does this by monitoring all domain controllers and directory processes at
once as a background process. If a problem occurs at any level in the directory, DirectoryAnalyzer alerts, or notifies,
your users. If the problem is critical, its integrated knowledge base contains descriptions and troubleshooting methods
that will help you solve it.
DirectoryAnalyzer monitors the individual structures and components of ADreplication, domains, sites, Global
Catalogs (GCs), operations master roles, and DNS (inasmuch as it relates to AD). Each of these components is
vital to the operation of AD. DirectoryAnalyzer can monitor and alert on specific conditions and problems in each
of the individual structures. The alerts are then recorded at the DirectoryAnalyzer client or console for viewing.
Alerts have two levels of severitywarning and critical. Warning alerts indicate that a predetermined threshold has
been met in one of the directory structures. Warning alerts help you identify when and where problems may occur.
Critical alerts indicate that a predetermined error condition has been met. Critical alerts are problems that need
your immediate attention; if you ignore them, AD could lose functionality or the directory altogether.
By clicking Current Alerts under View Status in the sidebar, you can display all of the alerts with their associated
type, time, and description. Figure 4.1 shows the Current Alerts screen in DirectoryAnalyzer. The alerts have been
recorded for the AD domain controllers, directory structures, and directory processes.
Figure 4.1: Direct or yAnalyzer allows you t o monit or t he ent ire direct or y for problems.
You can also send alerts to enterprise management systems using Simple Network Management Protocol (SNMP).
This allows you to integrate DirectoryAnalyzer alerts with management consoles such as HP OpenView and Tivoli.
Alerts can also be recorded in the Event Log of the Win2K system and viewed using the Event Viewer utility. (See
"Event Viewer" later in this chapter.)
DirectoryAnalyzer logs all alert activity to a history database. You can export the database and analyze alert activity
over time using a variety of formats, such as Microsoft Excel, Hypertext Markup Language (HTML), Dynamic
HTML (DHTML), and Rich Text Format (RTF). You can also identify trends in the data, finding cycles or periods
of high and low alert activity.
AppManager from Net IQ
AppManager from NetIQ Corporation is a suite of management products that manages and monitors the
performance and availability of Win2K. One of these management products allows you to monitor the performance
of AD. For example, AppManager verifies that replication is occurring and up-to-date for the directory by monitoring
the highest Update Sequence Number (USN) value for each domain controller. The USN is discussed in more
detail later in this chapter (see "Monitoring Replication"). In addition, inbound and outbound replication statistics
are tracked, as are failed synchronization requests for the directory.
AppManager also allows you to monitor the number of directory authentications per second and monitor the cache
hit rate of name resolution. Using this tool, you can monitor and track errors and events for trust relationships.
You can also log errors and events to enterprise management systems using SNMP. This means that SNMP traps
are generated and routed to a configured network manager.
In addition, you can use or run a set of prepackaged management reports that allow you to further analyze current
errors and events. You can also set up this utility to send e-mail and pager alerts when an event is detected.
Bui l t -In Tool s
In this section, Ill discuss System Monitor, Event Viewer, and REPADMIN.
Syst em Moni t or
For the domain controller in AD, one of the main monitoring utilities is System Monitor. This utility allows you
to watch the internal performance counters that relate to the directory on the domain controller. The directory
performance counters are software counters that the developers of AD have programmed into the system.
Using System Monitor, you can monitor current directory activity for the domain controller. Once youve installed
AD on a server, several performance countersfor replication activity, DNS, address book, LDAP, authentication,
and the database itselfmeasure the performance of the directory on that computer.
I discussed how to launch and use System Monitor in Chapter 3, so I wont repeat that information here. Instead,
Ill focus on how to use some of the more important performance counters that are available for AD. Remember,
System Monitor tracks all of its counters in real time. For this reason, I recommend that you always establish a
baseline or normal operation that you can compare the real-time values against. When adding AD counters to
System Monitor, if you dont understand the meaning of any counter, highlight it, then click Explain. The Explain
Text dialog box appears and provides a description of the counter.
You can also graph the performance counters and set alerts against them. The alerts will appear in the Event Viewer.
Event Vi ewer
To view and analyze the events that have been generated by a Win2K domain controller, you can use the Event
Viewer. This utility allows you to monitor the event logs generated by Win2K. By default, there are three event
logs: the application log, the system log, and the security log. (These three logs were described in the "Event
Viewer" section of Chapter 3.) In addition, after you install AD, three more logs are created.
Di rect ory servi ce l og
Contains the events that are generated by AD on the domain controller. You can use this log to monitor
activity or investigate any directory problems. By default, the directory records all critical error events.
DNS server l og
Contains the events generated by the DNS service installed on your domain controller. For example, when
the DNS service starts or stops, it writes a corresponding event message to this log. More critical DNS
events are also loggedfor example, if the service starts but cannot locate initializing data, such as zones or
other startup information stored in the domain controllers Registry or AD. The DNS log exists only if the
DNS service is running on the server. The DNS service typically runs on only a few domain controllers in
the forest.
Fi l e Repl i cat i on servi ce l og
Contains events generated by file replication on the domain controller. The File Replication service (FRS) is
a replication engine used to replicate files among different computers simultaneously. AD uses this service
to replicate Group Policy files among domain controllers.
Depending on how you configure your AD installation, you may have one or all of these logs on your domain
controller. Figure 4.2 shows the Event Viewer startup screen on a domain controller after youve installed AD with DNS.
Repl i cat i on Di agnost i cs (REPADMIN)
The Replication Diagnostics tool is simply referred to as REPADMIN. Its a command-line utility that allows you
to monitor and diagnose the replication process and topology in AD. It also provides a number of switches that you
can use to monitor specific areas of replication. For example, you can force replication among domain controllers
and view the status.
During normal replication, the Knowledge Consistency Checker (KCC) manages and builds the replication topology
for each naming context on the domain controller. The replication topology is the set of domain controllers that
shares replication responsibility for the domain. REPADMIN allows you to view the replication topology as seen
by the domain controller. If needed, you can use REPADMIN to manually create the replication topology, although
this isnt usually beneficial or necessary because its generated automatically by the KCC.
You can also view the domain controllers replication partners, both inbound and outbound, and some of the internal
structures used during replication, such as the metadata and up-to-dateness vectors.
You can install the REPADMIN.EXE utility from the Support\Tools folder on the Microsoft Windows 2000 CD.
Running the SETUP program launches the Win2K Support Tools Setup wizard, which installs this tool along with
many other useful support tools to the Program Files\Support Tools folder. Figure 4.3 shows the interface for
REPADMIN.
Figure 4.2: The Event Viewer st ar t up screen list s addit ional event logs t hat have been creat ed for AD.
Moni t ori ng t he AD Inf rast ruct ure
An important aspect of any AD deployment is always monitoring the environment and infrastructure. The
infrastructure of AD is the set of processes and data structures that the directory service uses to function properly.
By constantly monitoring the infrastructure, you can detect issues that arise in the environment and correct them
before they affect your users. For example, users will be affected if there is an intermittent failure of a bridgehead
server or if a Flexible Single Master Operation (FSMO, pronounced "fizmo") role-holding server goes down.
The first task in troubleshooting AD is to constantly monitor critical areas of the directory deployment. I
recommend that you continuously monitor at least the following directory structures and components:
Figure 4.3: The REPADMIN ut ilit y allows you t o view t he replicat ion process and t opology.
Domai n cont rol l ers
These are critical to the proper operation of AD. If one domain controller isnt functioning properly, the
directory and some users will lose performance and possibly functionality. If the domain controller that is
having problems has also been assigned additional vital roles (such as being a DNS or GC server), the
directory may become unavailable to all users. Thus, its critical to monitor and track the performance of all
domain controllers on the network at all times.
Domai n par t i t i on
Stores AD objects and attributes that represent users, computers, printers, and applications. The domain
partition is also used to accomplish a number of management roles, which include administration and
replication. You must monitor the performance and availability of the domain partition so that the services
it supports are constantly available.
GC par t i t i on
Stored on domain controllers throughout the network. Only a few domain controllers store a copy of the GC
partition, and they need to be monitored for the GC. GCs are specialized domain controllers whose
availability is necessary for clients to be able to log on to the network. The GC streamlines directory searches
because it contains all of the objects in the forest but only a few of their key attributes.
Operat i ons mast ers
These (or FSMO role holders) are single-master domain controllers that perform special roles for AD. Its
important that you monitor and track the performance of each operations master so that the service it
performs is maintained. If any operations master stops functioning, its functionality is lost in the directory.
Repl i cat i on process and t opol ogy
Are critical to the operation of AD. If changes have been made to a directory object on one domain controller,
the replication process needs to propagate the changes to all of the other domain controllers that have replicas
of that object. If replication isnt functioning, different portions of the directory get out of sync. This confuses
users, and they lose access to directory resources.
For example, if an administrator has changed a Group Policy but the change hasnt been synchronized to all
copies, users using the older copies may access the wrong information. In addition, once the synchronization
among directory replicas is lost, its very difficult and time-consuming to get back. Thus, its critical to
constantly monitor the replication process and topology for problems.
Moni t ori ng t he Domai n Cont rol l ers
Because AD can be distributed across many domain controllers, you need to constantly monitor individual domain
controllers. If one domain controller isnt functioning properly, the directory and your users will lose performance
and possibly functionality. If multiple domain controllers arent functioning properly, the network can become
unusable. For this reason, I recommend that you always check or monitor that the domain controllers hardware
and subsystems are operating correctly. (For details on how to monitor the hardware components of the domain
controller, refer to Chapter 3.) After youre confident that the hardware is performing well, you need to monitor
the AD services running on the domain controllers for errors and other problems.
Usi ng Di rect oryAnal yzer
Many third-party tools (such as those I discussed earlier) provide you with an easy way to monitor all of the
domain controllers in your forest from one management console. For example, in DirectoryAnalyzer, click Browse
Directory By Naming Context; the directory hierarchy is displayed. If you expand the naming contexts, you see all
of the associated domain controllers. To see the alerts for just one domain controller, select a domain controller
object, then click Current Alerts. The alerts that are displayed have exceeded a warning or critical threshold and
show the severity, subject, associated type, time, and description. Figure 4.4 shows an example of using
DirectoryAnalyzer to view all alerts for each domain controller.
DirectoryAnalyzer is an extremely useful utility because it monitors all of the domain controllers in the AD forest
as a background process and allows you to periodically view the results. It also monitors the most critical directory
structures and processesfor example, the configuration and activity for the domain partitions, GC partitions,
operations master roles, sites, DNS, the replication process, and the replication topology.
Figure 4.4: Direct or yAnalyzer allows you t o monit or all t he domain cont rollers in your forest for problems and see t he
aler t s t hat have been recorded for each domain cont roller.
To see t he aler t s and ot her informat ion for each domain cont roller, you can also use t he Browse Direct or y
By Sit e opt ion. It allows you t o browse t he direct or y layout according t o sit es and t heir associat ed domain
cont rollers. In addit ion, it permit s you t o view t he st at us of each sit e and t he sit e links.
In addition to viewing the alerts from the domain controllers, you can click any alert and see a more detailed
description of the problem. If you dont understand the alert, you can double-click it; the Alert Details dialog box
will appear and provide more description, as shown in Figure 4.5.
Figure 4.5: Direct or yAnalyzer provides more informat ion about an aler t in t he Aler t Det ails dialog box.
Once youve been notified of the alert and viewed more information about it in the Alert Details dialog box, you
can use the integrated knowledge base to help resolve the problem. The knowledge base provides you with a
detailed explanation of the problem, helps you identify possible causes, then helps you remedy or repair the problem.
To access the knowledge base, click More Info in the Alert Details dialog box or choose Help>Contents in the console.
Figure 4.6 shows an example of the information available in the knowledge base.
As you know by now, domain controllers are the workhorses of AD. They manage and store the domain information
and accept special functions and roles. For example, a domain controller can store a domain partition, store a GC
partition, and be assigned as a FSMO role owner. Domain controllers, in turn, allow the directory to manage user
interaction and authentication and oversee replication to the other domain controllers in the forest.
In addition to displaying alerts for each domain controller, DirectoryAnalyzer displays detailed configurations. For
example, when you choose Browse Directory By Naming Context, you see several icons for each domain controller.
An icon that includes a globe indicates that the domain controller stores a GC partition. When an icon displays
small triangles, it indicates that the domain controller is also providing the DNS service. An icon that displays both
a globe and small triangles indicates that the domain controller has both a GC and a DNS.
Figure 4.6: Direct or yAnalyzer s in-dept h knowledge base helps you find solut ions t o problems in AD.
If you select a domain controller, then click the DC Information tab, you can view detailed information about how
the domain controller is operating and handling the directory load. Figure 4.7 shows the DC Information pane in
DirectoryAnalyzer.
Figure 4.7: You can view det ailed informat ion about a domain cont roller using t he DC Informat ion pane in Direct or yAnalyzer.
DirectoryAnalyzer provides a high-level summary of how each domain and its associated domain controllers are
functioning. Click Browse Directory By Naming Context to see a high-level status of all the domain controllers in a
domain. To view the status for a particular domain, select it, then click the DC Summary tab. Figure 4.8 illustrates
the DC Summary pane, which uses green, yellow, and red icons to indicate the status of each domain controller in
a domain.
You can also quickly view where the domain controller resides, if its a GC, and who manages the computer. If any
of the domain controllers arent showing a green (clear) status icon, there is a problem that you need to investigate
and fix.
Usi ng NTDS Per formance Count ers
NTDS (NT Directory Service) performance counters are internal domain controller counters used by multiple
aspects of AD. Once AD has been installed on the domain controller, these directory counters are added to the
system. These counters allow you to monitor and track the domain controllers replication activity, LDAP traffic,
and authentication traffic. Table 4.1 describes the more useful NTDS performance counters and how to use them
to track AD activity on a domain controller.
Figure 4.8: The DC Summar y pane in Direct or yAnalyzer provides a high-level st at us of all domain cont rollers in a domain.
DRA Inbound
Bytes Total/sec
Indicates the total amount of inbound replication traffic over
time. If a small number of bytes are being sent, either the
network or the server is slow. Other issues that might limit the
number of bytes being sent include few changes being made
to the naming contexts hosted by the domain controller,
replication topology problems, and connectivity failures.
Of course, you need to check this value against a baseline
of activity.
Tracks the total
number of bytes
per second received
on the server during
replication with other
domain controllers.
Thi s Count er Does Thi s How t o Use It
DRA Inbound
Object Updates
Remaining in Packets
Indicates that the server is receiving changes but is taking a
long time to apply them to the AD database. The value of this
counter should be as low as possible. A high value indicates
that the network is slow during replication or the domain
controller is receiving updates faster than it can apply them.
Other issues that can affect speed of update are high domain
controller load, insufficient hardware (memory, disk, or CPU),
the disk becoming full or fragmented, other applications
using too many resources, and so on.
Tracks the number
of object updates
received in the AD
replication update
packet but not applied
to the local domain
controller.
DRA Outbound
Bytes Total/sec
Indicates the total amount of outbound replication traffic
over time. If this value remains low, it can indicate a slow
server or network or few updates on this domain controller.
In the latter case, it can mean that clients are connecting to
other domain controllers because this one is slow or that
there are topology problems. For best results, test the current
value against an established baseline value.
Tracks the number
of bytes that are sent
from the server
during replication
to other domain
controllers.
DRA Pending
Replication
Synchronizations
Indicates the backlog of directory synchronizations for the
selected server. This value should be as low as possible. A
high value could indicate a slow server or a problem with
the servers hardware.
Tracks the number of
pending requests from
replication partners for
this domain controller
to synchronize with
them. Synchronizations
are queued, ready for
processing by the
domain controller.
DS Threads in Use Indicates how the directory service on the server is responding
to client requests. When a client requests information, AD
spawns a thread to handle the request. If the number of
threads remains constant, Win2K clients may experience
a slow response from the domain controller.
Tracks the current
number of threads
that are being used
by the directory
service running on the
domain controller.
Kerberos
Authentications/sec
Indicates how the domain controller is responding to client
requests for authentications. If this counter doesnt show
activity over time, clients could be having a problem contacting
the domain controller.
Tracks the current
number of authentica-
tions per second for
the domain controller.
LDAP Bind Time This counter tracks only the last successful bind for an
LDAP client. The value of this counter should be as low as
possible to indicate that the domain controller was quick to
authenticate the LDAP client. If the value is high, the
domain controller was slow to authenticate LDAP. A high
value can indicate a server problem, the domain controller is
too busy, insufficient hardware (memory or CPU), or other
applications using too many resources.
Tracks the amount of
time (in milliseconds)
required to process the
last LDAP bind
request from the client.
A bind is described as
authenticating the
LDAP client.
NTDS counters enable you to monitor the performance of AD for the selected domain controller. You can view
these counters under the NTDS object in System Monitor (see Figure 4.9). By default, System Monitor is started
when you choose Start>Administrative Tools>Performance Console.
LDAP Client
Sessions
If your domain controller has LDAP clients trying to connect,
the value of this counter should show activity over time. If the
value remains constant, the server or client may have problems,
the domain controller may be too busy running other applica-
tions, or there is insufficient hardware (memory or CPU).
Tracks the current
number of LDAP
sessions on the selected
domain controller.
LDAP Searches/sec Indicates how many LDAP search requests the domain
controller is servicing per second. You typically view different
search rates depending on the domain controllers hardware,
the number of clients connected to the domain controller,
and what sorts of things the clients are doing.
Tracks the number
of LDAP search
operations that were
performed on the
selected domain
controller per second.
LDAP clients connect-
ing to the server
perform the LDAP
search operations.
LDAP Successful
Binds/sec
Indicates how the domain controller responds to authentications
from the clients. This value allows you to view the number of
successful binds per second for LDAP clients. Again, if this value
remains constant over time, there can be a network, client, or
server problem. For example, there is a bad network component,
the client is too busy, or the server is too busy.
LDAP binds per
second that occur
successfully.
NTLM
Authentications
Allows you to see whether there are authentications from
Windows 98 and NT clients for this domain controller. If
youre supporting Windows 98 and NT and the value remains
constant over time, there is a network problem. For example,
the network could have a bad or poorly configured component,
or the client could be too busy.
Tracks the total
number of Windows
NT LAN Manager
(NTLM) authentica-
tions per second
serviced by the
domain controller.
Table 4.1: A few of t he NTDS per formance count ers t hat allow you t o t rack how a domain cont roller is responding t o replicat ion
t raf fic, LDAP t raf fic, and aut hent icat ion t raf fic.
Moni t ori ng t he Domai n Par t i t i ons
Domain partitions in AD are often referred to as naming contexts, and they provide a security and replication
boundary. Each domain partition exists in the NTDS.DIT database on the domain controllers that participate in
the domain. The domain partition stores all the users, printers, servers, computers, and application data. Because
users depend on the domain to access other network resources, its important that you constantly monitor the state
of the domain partition.
DirectoryAnalyzer allows you to monitor the alerts for each domain in AD and the associated domain controllers.
These alerts monitor the domain controllers, replicas, group policies, trust relationships, DNS, and other activity
for a domain. If you see any critical alerts, you need to investigate and fix the problems.
To view the alerts for a domain, click Browse Directory By Naming Context. Select a domain, then click the
Current Alerts tab. The display shows the current alerts for that domain (see Figure 4.10).
Figure 4.9: NTDS per formance count ers allow you t o monit or and t rack load and per formance of t he AD
implement at ion on each domain cont roller.
In addition to displaying alerts for each domain, DirectoryAnalyzer allows you to view configuration information.
Using the Naming Context Information tab, you can view the current number of alerts that are active for the
following areas: Naming Context (or Domain), Replica, DNS Server, and DC Server.
The Naming Context Information tab also displays the number of domain controllers for the domain and whether
the domain supports mixed mode. When a domain supports mixed mode, it allows replication and communication
with down-level domain controllers and clients to occur. In addition, you can see which domain controllers in the
domain are performing the operations master roles and an operations master consistency check. And finally, you
can view all the trust relationships that exist for the domain. Figure 4.11 shows the Naming Context Information
pane in DirectoryAnalyzer.
Figure 4.10: Direct or yAnalyzer allows you t o monit or each domain par t it ion for problems.
To further monitor the domain, DirectoryAnalyzer provides a high-level summary of each domain controller. Click
Browse Directory By Naming Context, then click the DC Summary tab. (The DC Summary pane is shown in
Figure 4.8 earlier in this chapter.)
Usi ng Domai n Dat abase Per formance Count ers
In AD, the database for the domain has been implemented as an indexed sequential access method (ISAM) record or
table manager. This table manager is often referred to as the Extensible Storage Engine (ESE) and is implemented by
ESENT.DLL on the server. By default, the associated database file is stored on the Win2K server as
<drive>\WINNT\NTDS\NTDS.DIT.
Figure 4.11: The Naming Cont ext Informat ion pane in Direct or yAnalyzer allows you t o see det ailed informat ion for a domain.
If necessar y, you can relocat e t he NTDS.DIT dat abase on a domain cont roller using t he NTDSUTIL ut ilit y.
Using this database engine, AD provides a set of database performance counters that allow you to monitor the
domain in depth. These counters provide information about the performance of the database cache, database files,
and database tables, and they help you monitor and determine the health of the database for the domain controller.
By default, database performance counters arent installed on the domain controllers. (For instructions on installing
them, see "Installing the Counters" below.)
You can view and monitor database counters using the System Monitor utility. Table 4.2 gives you a general
description of the more useful database performance counters and how to use them to track the activity of the
low-level database for each domain.
Cache % Hits
Indicates how database requests are performing. The
value for this counter should be at least 90%. If its lower
than 90%, the database requests are slow for the domain
controller, and you should consider adding physical
memory to create a larger cache.
Tracks the percentage
of database page requests
in memory that were
successful. A cache hit is
a request that is serviced
from memory without
causing a file-read
operation.
Thi s Count er
Cache Page
Faults/sec
Indicates how the database cache is performing. I recommend
that the computer have enough memory to always cache
the entire database. This means that the value of this counter
should be as low as possible. If the value is high, you need
to add more physical memory to the domain controller.
requests (per second)
that cannot be serviced
because no pages are
available in cache. If
there are no pages, the
database cache manager
allocates new pages for
the database cache.
File Operations
Pending
Indicates how the OS handles the read/write requests to
the AD database. I recommend that the value for this
counter be as low as possible. If the value is high, you
need to add more memory or processing power to the
domain controller. This condition can also occur if the
disk subsystem is bottlenecked.
pending requests issued
by the database cache
manager to the database
file. The value is the
number of read and write
requests that are waiting
to be serviced by the OS.
File Operations/sec Indicates how many file operations have occurred for the
AD database. I recommend that this value be appropriate
for the purpose of the domain controller. If you think
that the number of read and write operations is too high,
you need to add memory or processing power to the
computer. However, adding memory for the file system
cache on the computer reduces file operations.
requests (per second)
issued by the database
cache manager to the
database file. The value is
the read and write
requests per second that
are serviced by the OS.
Does Thi s How t o Use It
Table Open Cache
Hits/sec
Indicates how the AD database is performing. The value
for this counter should be as high as possible for good
performance. If the value is low, you may need to add
more memory.
database tables opened
per second. The database
tables are opened by the
cached schema
information.
Table 4.2: Some of t he more useful dat abase per formance count ers, which allow you t o monit or t he dat abase for t he domain
par t it ion t hat st ores all of t he AD object s and at t ribut es.
Inst al l i ng t he Count ers
By default, database performance counters arent installed on the domain controller. To install them, you must use the
dynamic-link library (DLL) file called ESENTPRF.DLL. The instructions for installing the counters are as follows:
1. Copy the %System%\System32\ESENTPRF.DLL file to a different directory. For example, you can
create a directory named C:\Perfmon, then copy the file to it.
2. Run the REGEDT32.EXE or REGEDIT.EXE Registry Editor and create the following Registry subkeys
if they dont already exist:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\
Performance
3. Under the Performance subkey that you added in Step 2, add and initialize the data of the following
Registry values:
Open: REG_SZ: OpenPerformanceData
Collect: REG_SZ: CollectPerformanceData
Close: REG_SZ: ClosePerformanceData
Library: REG_SZ: C:\Performance\esentprf.dll
4. Change directory to the %SystemRoot%\System32 folder (for example, C:\Winnt\System32).
5. Load the counter information into the Registry by executing the following statement:
LODCTR.EXE ESENTPERF.INI
Once youve installed the database performance counters, you can use them to track and monitor the database on
the domain controller. As mentioned earlier in "Using NTDS Performance Counters," you can view and track each
counter using the System Monitor utility in the Performance Console.
Moni t ori ng t he Gl obal Cat al og
As Ive discussed in previous chapters, special servers on Win2K networks store a Global Catalog (GC) partition,
which is replicated in AD. The domain controllers that contain the GC partition are referred to as GC servers.
Because only the first domain controller installed in a forest is made a GC, you need to determine and specify
which subsequent domain controllers will act as GC servers. In addition, you need to constantly monitor the GC
partition to ensure that it remains healthy.
The GC has been designed to support two crucial functions in an AD forest: user logons and forest-wide queries or
searches. It does this by storing all of the objects in the forest and the key attributes for each. It doesnt store all the
attributes for each object; instead, it stores only the attributes it needs to perform queries and support the logon
process. One of these attributes is the distinguished name of the object.
Once users query and retrieve the distinguished name from the GC, they can issue a search on their local domain
controller, and LDAP will chase the referrals to the domain controller that stores the real object information. In
addition, universal group membership is stored in the GC. Because universal groups can deny access to resources, a
users membership in this group must be discovered during logon to build the logon access token. The requests
made to the GC are automatic and not seen by the user.
You can use DirectoryAnalyzer to monitor the GC partition and how its performing. It monitors and tracks the
following conditions:
Domai n Cont rol l er: Gl obal Cat al og Load Too Hi gh
Indicates that the domain controller that stores the GC partition has too much traffic. This is LDAP traffic
coming from workstations and servers.
Domai n Cont rol l er: Gl obal Cat al og Response Too Sl ow
Indicates that the domain controller that stores the GC partition isnt responding in time to queries and
other traffic.
Repl i ca: GC Repl i cat i on Lat ency Too Hi gh
Indicates that replication is taking too long to synchronize the GC stored on the domain controller. If
replication latency (the time it takes to replicate changes to all GCs in the forest) is too high, an alert is
generated.
Si t e: Too Few Gl obal Cat al ogs i n Si t e
Indicates that there arent enough GC servers in the site.
Figure 4.12 shows how DirectoryAnalyzer monitors and tracks alerts for the GC.
Figure 4.12: Direct or yAnalyzer allows you t o monit or t he GC par t it ion t hat exist s on various domain cont rollers t hroughout t he forest .
Moni t ori ng Operat i ons Mast ers
To prevent conflicting updates in Win2K, AD provides a single-master server to update certain operations. In a
single-master model, only one server is allowed to provide updates for the forest or domain. When a domain
controller takes on the responsibility of the single-master operation, its taking on a role. Thus, this method of
updates is called single-master operation roles. When only one domain controller can take on the role at one
time, its referred to as a Flexible Single Master Operation (FSMO) role.
There are currently five types of operations masters in AD. The directory automatically elects the operations master
servers during the creation of each AD forest and domain. (For more detail on these FSMOs, see Chapter 1.)
Two operations masters manage forest-wide operations, so have forest-specific FSMO roles.
Schema mast er
Responsible for schema extensions and modifications in the forest
Domai n nami ng mast er
Adds and removes domains in the forest.
Three operations masters manage domain operations and so have domain-specific FSMO roles.
Infrast ruct ure mast er
Updates group-to-user references in a domain
RID mast er
Assigns unique security IDs in a domain
PDC emul at or
Provides primary domain controller support for down-level clients in a domain.
The t hree domain-specific FSMO roles exist in ever y domain. Thus, an AD forest wit h a t ot al of 3 domains
would have 11 FSMO roles in all: 9 domain-specific roles and 2 forest -wide roles.
Because there is only one of each of the forest-specific FSMO roles, its extremely important that you constantly
monitor and track the activity and health of the operations masters. If any of them fail, the directory loses functionality
until the computer is restarted or another appropriate domain controller is assigned the role.
To monitor operations masters, you can use DirectoryAnalyzer. It monitors, checks the status of, and alerts on several
types of conditions and situations relating to operations masters, such as which domain controllers are holding the
operations masters. Click Browse Directory By Naming Context, and click the Naming Context Information tab.
Under Operations Master Status, you see which domain controller is holding which FSMO. Figure 4.13 shows the
status of operations masters in the Naming Context Information pane.
You can also use the Naming Context Information pane (shown in Figure 4.13 above) to check the consistency of
the operations masters across all of the domain controllers on the network. DirectoryAnalyzer monitors what each
domain controller reports for the FSMO assignments. If not all of the domain controllers report the same values
for all of the operations masters, the word No appears beside Operations Master Consistent.
To investigate the problem, click Details. The Operations Master Consistency dialog box appears, indicating that
operations master information is inconsistent. It displays the names of the domain controllers and which domain
controller holds each operations master. In Figure 4.14 below, the domain controller COMP-DC-04 has inconsistent
information about the true owner of the PDC operations master because it shows domain controller COMP-DC-01
as the owner when it should be COMP-DC-03. Thus, the owner of the PDC operations master is inconsistent.
Figure 4.13: Direct or yAnalyzer displays which domain cont rollers are holding which operat ions mast ers for t he naming cont ext .
In addition to showing the status and consistency checks, DirectoryAnalyzer monitors and displays alerts for each
operations master. The alerts that are monitored and tracked provide information about the availability of the FSMOs.
To monitor the availability of the operations masters, you can click Current Alerts in the sidebar on the main screen.
To display the alerts for a domain or each domain controller, click Browse Directory By Naming Context.
The alerts indicate that the domain controller that holds the operations master isnt responding. This could mean that
the domain controller and AD are down and not responding. It could also mean that the domain controller no longer
has network connectivity, and this could indicate DNS or Internet Protocol (IP) addressing problems. Finally, this
alert could simply mean that the domain controller or the directory that is installed is overloaded and responding too
slowly. Figure 4.15 shows how DirectoryAnalyzer monitors and tracks alerts for each operations master.
Figure 4.14: Direct or yAnalyzer allows you t o monit or and check consist ency for each operat ions mast er.
Moni t ori ng Repl i cat i on
AD is a distributed directory made up of one or more naming contexts, or partitions. Partitions are used to distribute
the directory data on the domain controllers across the network. The process that keeps partition information up
to date is called replication. Monitoring replication is critical to the proper operation of the directory. Before I
discuss how to monitor replication, however, I need to describe what it is and how it works.
In AD, replication is a background process that propagates directory data among domain controllers. For example,
if an update is made to one domain controller, the replication process is used to notify all of the other domain
controllers that hold copies of that data. In addition, the directory uses multimaster replication; this means that
there is no single source (or master) that holds all of the directory information. Using multimaster replication,
changes to the directory can occur at any domain controller; the domain controller then notifies the other servers.
Because AD is partitioned, not every domain controller needs to communicate or replicate with each other. Instead,
that system uses a set of connections that determines which domain controllers need to replicate to ensure that the
appropriate domain controllers receive the updates. This approach reduces network traffic and replication latency
(the time to replicate a change to all replicas). The set of connections used by the replication process is the
replication topology.
Figure 4.15: Direct or yAnalyzer monit ors and t racks t he availabilit y of each operat ions mast er.
Usi ng Di rect ory Par t i t i on Repl i cas
A directory partition replica can be a full replica or a partial replica. A full replica contains all of the objects and
attributes of a partition and is read- and write-accessible. A partial replica contains a subset of the objects and
attributes and is read-only. Partial replicas are stored only on a GC server. Each domain controller stores at least
three full directory partitions, or naming contexts, which include the schema partition, configuration partition, and
domain partition.
Schema Par t i t i on
The schema partition contains the set of rules that defines the objects and attributes in AD. This set of rules is used
during creation and modification of the objects and attributes in the directory. The schema also defines how the
objects and attributes can be manipulated and used in the directory.
The schema partition is global; this means that every domain controller in the forest has a copy, and these copies
need to be kept consistent. To provide this consistency, the replication process in the directory passes updated
schema information among the domain controllers to the copies of the schema. For example, if an update is made
to the schema on one domain controller, replication propagates the information to the other domain controllers, or
copies of the schema.
Confi gurat i on Par t i t i on
The configuration partition contains the objects that define the logical and physical structure of the AD forest.
These objects include sites, site links, trust relationships, and domains. Like the schema partition, the configuration
partition exists on every domain controller in the forest and must be exactly the same on each one.
Because the configuration partition exists on every domain controller, each computer has some knowledge of the
physical and logical configuration of the directory. This knowledge allows each domain controller to efficiently
support replication. In addition, if a change or update is made to a domain controller and its configuration partition,
replication is started, which propagates the change to the other domain controllers in the forest.
Domai n Par t i t i on
The domain partition contains the objects and attributes of the domain itself. This information includes users,
groups, printers, servers, organizational units (OUs), and other network resources. The domain partition is copied,
or replicated, to all of the domain controllers in the domain. If one domain controller receives an update, it needs
to be able to pass the update to other domain controllers holding copies of the domain.
A read-only subset of the domain partition is replicated to GC servers in other domains so that other users can
access its resources. This allows the GC to know what other objects are available in the forest.
Usi ng Di rect ory Updat es
AD updates are changes made to an object or attribute stored on a domain controller. When an update occurs, the
domain controller that receives it uses replication to notify other domain controllers holding replicas of the same
partition. The domain controller that receives the update (called the originating domain controller) notifies its
replication partners of the change first, then the partners requesting the appropriate changes.
A write request from a directory client is called an originating write. When an update that originates on one
domain controller is replicated to another domain controller, the update is called a replicated write. Using this
approach, AD can distinguish update information during replication.
AD replication doesnt use date or time stamps to determine what changes need to be propagated among domain
controllers; instead, it uses Update Sequence Numbers (USNs). A USN is a 64-bit counter that is associated with
each object. It increments each time a change is initiated, then its associated with the change. To view the USN of
an object, use the following command at a command prompt:
REPADMIN / showmet a <obj ect DN>
In addition to maintaining USNs, AD maintains an up-to-dateness vector, which helps the domain controllers
involved in replication track updates. The up-to-dateness vector is a table containing one entry per naming context,
which are the high-watermark USNs for each replication partner. During replication, the requesting domain
controller sends the up-to-dateness vector with its replication request so that the originating domain controller
sends only those updates that the requesting domain controller doesnt already have.
The up-to-dateness vector also helps with the problems of multiple replication paths among domain controllers.
AD allows multiple replication paths to exist so that domain controllers can use more than one path to send and
receive replication traffic. When multiple replication paths exist, you might expect redundant traffic and endless
looping during replication, but the directory allows domain controllers to detect when replication data has already
been replicated. This method is called propagation dampening.
AD prevents these potential problems by using the up-to-dateness vector and the high-watermark vector. The
up-to-dateness vector contains serverUSN pairs and represents the latest originating update. The high-watermark
vector holds the USNs for attributes that have been added or modified in the directory and that are stored in the
replication metadata for that attribute. Using both vectors, propagation dampening can occur and unnecessary
directory updates avoided.
As Ive mentioned, the values in the up-to-dateness vector can determine which updates need to be sent to the
destination domain controller. For example, if the destination domain controller already has an up-to-date value
for an object or attribute, the source domain controller doesnt have to send the update for it. To view the contents
of the up-to-dateness vector for any domain controller, type the following command at a command prompt:
REPADMIN / showvect or <NC name>
To help resolve conflicts during replication, AD attaches a unique stamp to each replicated value. Each stamp is
replicated along with its corresponding value. To ensure that all conflicts can be resolved during replication, the
stamp is compared with the current value on the destination domain controller. If the stamp of the value that was
replicated is larger than the stamp of the current value, the current value (including the stamp) is replaced. If the
stamp is smaller, the current value is left alone.
Usi ng t he Repl i cat i on Topol ogy
As I mentioned earlier, the replication topology is the set of connections used by the domain controllers in a forest
to synchronize the directory partition replicas. The replication topology is created automatically on the basis of
information in AD by the Knowledge Consistency Checker (KCC), a built-in process that runs on all domain
controllers. By default, the KCC runs at 15-minute intervals and designates the replication routes among domain
controllers on the basis of the most favorable connections available at that time.
The KCC automatically generates replication connections among domain controllers in the same site. This local
replication topology is called an intra-site topology. If you have multiple wide area network (WAN) locations, you
can configure site links among the sites, then the KCC can automatically create the respective replication connection
objects. The replication topology that is created among remote locations is called an inter-site topology. The sets of
domain controllers that replicate directly with each other are called replication partners. Each time the KCC runs,
these replication partners are automatically added, removed, or modified.
Alt hough you can disable t he KCC and creat e connect ion object s by hand, I st rongly recommend t hat you
use t he KCC t o aut omat ically generat e t he replicat ion t opology. The reason is t hat t he KCC simplifies a
complex t ask and has a flexible archit ect ure, which react s t o changes you make and any failures t hat
occur. However, if your organizat ion has more t han 100 sit es, you may need t o manually creat e t he
replicat ion t opology; above t his number, t he KCC doesn t scale well.
The KCC uses the following components to manage the replication topology:
Connect i ons
The KCC creates connection objects in AD that enable the domain controllers to replicate with each other.
A connection is defined as a one-way inbound route from one domain controller to another. The KCC
manages the connection objects and reuses them where it can, deletes unused connections, and creates new
connections if none exist.
Servers
Each domain controller in AD is represented by a server object. The server has a child object called NTDS
Setting. This setting stores the inbound connection objects for the server from the source domain controller.
Connection objects are created in two waysautomatically by the KCC or manually by an administrator.
Si t es
The KCC uses sites to define the replication topology. Sites define the sets of domain controllers that are
well connected in terms of speed and cost. When changes occur, the domain controllers in a site replicate
with each other to keep AD synchronized. If the domain controllers are local (intra-site topology), replication
starts as needed with no concern for speed or costwithin five minutes of an update occurring. If the two
domain controllers are separated by a low-speed network connection (inter-site topology), replication is
scheduled as needed. Inter-site replication occurs only on a fixed schedule, regardless of when updates occur.
Subnet s
Subnets assist the KCC to identify groups of computers and domain controllers that are physically close or
on the same network.
Si t e l i nks
Site links must be established among sites so that replication among sites can occur. Unless a site link is
placed, the KCC cannot automatically create the connections among sites, and replication cannot take
place. Each site link contains the schedule that determines when replication can occur among the sites that
it connects.
Bri dgehead servers
The KCC automatically designates a single server for each naming context, called the bridgehead server, to
communicate across site links. You can also manually designate bridgehead servers when you establish each
site link. Bridgehead servers perform site-to-site replication; in turn, they replicate to the other domain
controllers in each site. Using this method, you can ensure that inter-site replication occurs only among
designated bridgehead servers. This means that bridgehead servers are the only servers that replicate across
site links, and the rest of the domain controllers are updated within the local sites.
DirectoryAnalyzer allows you to monitor replication among domain controllers and report any errors or problems.
It allows you to track the following problems and issues:
Repl i cat i on Cycl e
The time during which the requesting domain controller receives updates from one of its replication
neighbors. You can view the successful replication cycle as well as any errors that occurred during that time.
Repl i cat i on Lat ency
The elapsed time between an object or attribute being updated and the change being replicated to all the
domain controllers that hold copies. If replication latency is too high, DirectoryAnalyzer issues an alert.
Repl i cat i on Topol ogy
The paths among domain controllers used for replication. If the replication topology evaluates that the
topology is transitively closed (meaning that it doesnt matter on which domain controller an update
occurs), the topology will provide for that update to be replicated to all other domain controllers.
Repl i cat i on Fai l ures
Occur when a domain controller involved in replication doesnt respond. Each time there are consecutive
failures from the same domain controller, an alert is issued. Many things can cause failuresfor example, a
domain controller may be too busy updating its own directory information from a bulk load.
Repl i cat i on Par t ners
Sets of domain controllers that replicate directly with each other. DirectoryAnalyzer monitors domain
controllers and pings them to make sure that each is still alive and working. If a replication partner doesnt
respond, an alert is issued.
Repl i cat i on Confl i ct
Occurs when two objects or attributes are created or modified at exactly the same time on two domain
controllers on the network. AD resolves this conflict automatically, and DirectoryAnalyzer issues an alert so
that youll know that one of the updates was ignored by replication.
DirectoryAnalyzer is a unique utility because it allows you to browse AD for information on, for example, the
replication cycle and replication partners. Figure 4.16 shows the Replication Information pane, which displays the
last successful replication cycle for each domain controller, replication partners, and any errors that occurred during
replication.
Figure 4.16: Direct or yAnalyzer allows you t o view t he replicat ion cycle and replicat ion par t ners for each domain cont roller.
Using DirectoryAnalyzer, you can monitor and track the replication process for errors. If a problem occurs, the utility
will issue an alert to indicate what type of problem has occurred. You can double-click the alert to see more detailed
information, then use the knowledge base to find troubleshooting methods to help you solve the problem. The
Current Alerts screen displays the more recent alerts that have been logged for replication (see Figure 4.17 below).
You can also view the replication-related alerts that have been stored in the Alert History file in DirectoryAnalyzer.
To display these alerts, on the Current Alerts screen, choose Reports>Alert History. On the Report page, select one
of the report options to specify what alerts you want to include. Then select Preview to display the report on the
screen. You can print the report or export it to a file. Figure 4.18 illustrates an Alert History report.
Figure 4.17: The Current Aler t s screen in Direct or yAnalyzer allows you t o view t he most recent aler t s for t he replicat ion process.
Summary
Before you can accurately troubleshoot AD, you must be able to effectively monitor it for problems. This means
that you must be able to monitor the directory that has been distributed across domain controllers on the network.
You can do this by using the monitoring tools described in this chapter. These tools allow you to watch the directory
components individually and as they interact with each other. For example, you can monitor the domain controllers,
the domain partition, the GC partition, the operations masters, and the replication process and topology. Monitoring
these components ensures the health of the directory as a system.
Figure 4.18: Using Direct or yAnalyzer, you can produce a repor t of replicat ion-relat ed aler t s.
Chapt er 5
Troubl eshoot i ng Act i ve Di rect ory
Troubleshooting Active Directory (AD) means analyzing and identifying problems that occur in your AD network
and subsequently repairing them. Troubleshooting a production AD environment can often be difficult because its
dynamic and complex by nature, but there are techniques and tools available to make the job easier. In this chapter,
youll learn how to apply these techniques and tools and develop an AD network-troubleshooting methodology.
The troubleshooting process primarily involves isolating and identifying a problem. Few problems are difficult to
solve once you know exactly what is going wrong and where. Troubleshooting, in general, is more an art born out
of experience than an exact science. Your approach to solving a problem can depend largely on the specifics of your
directory, system, and network. This chapter outlines some common techniques and approaches that you can use to
help troubleshoot and maintain your implementation of AD.
Fol l owi ng a Speci f i c Troubl eshoot i ng Met hodol ogy
When you troubleshoot AD, I recommend that you follow a specific methodology of diagnosing and troubleshooting
problems in the system. This methodology is a set of steps you can follow to identify situations, diagnose problems,
and repair AD components. The first step of this methodology is a set of questions that you can use to identify
particular situations or problems.
Is network communication working?
Does the name resolution work?
Are the domain controllers responding?
Are the operations masters working?
Is the replication topology working?
When a problem doesnt exhibit the characteristics of a typical failure, and when monitoring tools fail to provide
enough information to isolate the problem, the next step is to try to eliminate pieces of the system until you end
up with a small, predictable failure. As I mentioned earlier, use the process of elimination to rule out as many
technologies and dependencies as possible. Even if the problem seems overly complex at first, you can simplify it
by eliminating all of the possibilitiesone by one.
Troubl eshoot i ng Net work Connect i vi t y
You can troubleshoot network connectivity in a number of ways. For example, you can:
Test that the hardware youre using has network connectivity
Test that Internet Protocol (IP) addresses are correct using the IPCONFIG utility
Test that Transmission Control Protocol/Internet Protocol (TCP/IP) connections are working using the
PING utility
Perform other troubleshooting tests using DirectoryAnalyzer.
Test i ng for Net work Connect i vi t y
The first step toward identifying and diagnosing AD problems is to verify that each domain controller and user
workstation has network connectivity. At a minimum, you need to check that your domain controllers hardware
is functioning correctly, including the computers local area network (LAN) adapters, drivers, cables, and network
hub. For example, if you look in the Network and Dial-up Connections screen under Control Panel and the Local
Area Connection icon is marked with a red X, the network cable isnt connected.
Figure 5.1 shows that the domain controller has a local area connection problem. Because the domain controllers
cable isnt connected to the network, there is a simple solution to the problem: reconnect the cable.
Test i ng t he IP Addresses
Another method of checking network connectivity on the LAN is to make sure that the IP addresses are correct. To
perform an IP check, use the IP Configuration utility (IPCONFIG). IPCONFIG allows you to view and modify the
domain controllers IP configuration details on the command line. It also checks that the default gateway is on the
same subnet as the local computers IP address. For Domain Name System (DNS) dynamic updates, you can use
IPCONFIG to register the computers entries in the DNS service.
To view a computers TCP/IP configuration, type the following command in a Command Prompt window on the
domain controller or workstation:
IPCONFIG /ALL
The default display shows only the IP address, subnet mask, and default gateway for each adapter bound to
TCP/IP. Figure 5.2 shows an unsuccessful TCP/IP configuration and network connection.
Figure 5.1: A red X on t he Local Area Connect ion icon indicat es t hat t he net work cable is disconnect ed from your domain cont roller.
Listing 5.1 shows a well-connected LAN. Notice that the IP addresses are displayed with appropriate values.
Figure 5.2: An unsuccessful TCP/ IP configurat ion and net work connect ion, shown using IPCONFIG.
C:> ipconfig /all
Windows 2000 IP Configuration
Host Name .......................... : cx266988-S
Primary DNS Suffix ................ : company.com
Node Type .......................... : Hybrid
IP Routing Enabled .................. : No
WINS Proxy Enabled .................. : No
Search List ........................ : company.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix ..... : company.com
Description ........................ : Netelligent 10/100TX PCI Embedded
UTP Coax Controller
Physical Address ................... : 00-80-5F-A9-C0-74
IP Address ......................... : 10.0.0.10
Subnet Mask ........................ : 255.255.0.0
Default Gateway .................... : 10.0.0.1
If you want to save the results of running IPCONFIG for further analysis, you can capture the results in a text file.
At the command line, enter the following command:
IPCONFIG /ALL > <local_drive>:\<text_file.txt>
List ing 5.1: A well-connect ed LAN, shown using IPCONFIG.
There are many advanced feat ures and swit ches available wit h IPCONFIG. To view t he available swit ches,
ent er:
IPCONFIG /?
If everything looks normal when you run IPCONFIG, go on to test the TCP/IP connection.
Test i ng t he TCP/ IP Connect i on
You can test the TCP/IP connection among connected servers and workstations using the PING utility. PING allows
you to determine whether the LAN adapter and TCP/IP are working and whether you have network connectivity to
the default gateway or the Dynamic Host Configuration Protocol (DHCP) server. In this case, you can use the
PING command to test TCP/IP connectivity among the domain controllers that support AD or on a workstation
that uses AD. You can start the PING command on one domain controller to test the connectivity to another.
When a domain controller fails to connect to the targeted computer, the PING utility returns a "Request timed
out" or "Destination host unreachable" message. This message is repeated at least four times as PING retries the
connection. In addition, the utility shows statistics gathered during the test.
You can use the PING utility to perform a series of steps to troubleshoot connectivity problems among domain
controllers. The first test is called the loop-back address test, which verifies whether TCP/IP is working on the local
computer. To perform this test on the local computer, type the following command in the Command Prompt window.
(Instead of using 127.0.0.1, you can use the keyword localhost.)
PING 127.0.0.1
If the PING command fails on the loop-back address test, check the TCP/IP configuration settings and restart the
local domain controller.
After you verify that TCP/IP is configured properly and the PING loop-back address test succeeds, you need to test
the local TCP/IP address of the local domain controller. To do this, type the following command:
PING <local_TCP/IP_address>
If the PING test for the local address fails, restart the domain controller and check the routing tables using the
ROUTE PRINT command at a command prompt on the computer. The ROUTE PRINT command displays the
current IP address assigned to the local computer plus all of the active and persistent network routes. This command
allows you to view and troubleshoot the network configurations that exist at the time that the command is executed.
After youve verified that the local address is working properly, use the PING command to check the communication
WNTIPCFG.EXE in t he Windows 2000 Resource Kit
If you re wondering why Windows 2000 (Win2K) doesn t contain a graphical TCP/ IP configuration utility similar
t o t he WINIPCFG.EXE file provided wit h Windows 95/ 98/ Me, you re not alone. A graphical user int er face
(GUI)-based TCP/ IP configurat ion ut ilit y (WNTIPCFG.EXE) is included in t he Windows 2000 Professional and
Windows 2000 Ser ver resource kit s, but by default , t he ResKit Set up ut ilit y doesn t inst all it . To inst all it ,
you need t o manually ext ract t he WNTIPCFG.EXE file from t he NETMGMT.CAB file, included in t he Resource
Kit s main inst allat ion folder, ont o your hard disk. (A similar sit uat ion exist ed wit h NT 4.0. The Windows NT
Ser ver Resource Kit included WNTIPCFG.EXE but didn t inst all it by default .) What s more, t he Windows
2000 Resource Kit Supplement 1 doesn t cont ain t he WNTIPCFG.EXE file, so t o obt ain it , you need t he
original Resource Kit .
to the other domain controllers in the same location or subnet. For example, you can check connectivity to the
other domain controllers on the same subnet as follows:
PING <domain_controller1_address>
In the PING statements, the domain controller address is represented as the domain name (that is, COMPANY.COM)
or the IP address of the domain controller (that is, 10.0.0.10). If communication among the domain controllers on
the local subnet fails, you need to check that each computer is operational and that the network hubs and switches
are working properly. If the domain controllers are separated by a wide area network (WAN) connection, you need
to ping the default gateways that route the TCP/IP traffic among WAN locations.
Start by pinging the IP address of your default gateway. If the PING command fails for the gateway, you need to
verify that the address for the default gateway is correct and that the gateway (router) is operational.
Next, ping the IP address of the remote domain controllers on the remote subnet as follows:
PING <remote_domain_contoller1_address>
In the PING statements, the remote domain controller address is represented as the domain name (that is,
REMOTE.COMPANY.COM) or the IP address of the domain controller (that is, 20.0.0.20). If the PING
command fails, verify the address of each remote domain controller and check whether each remote domain
controller is operational. In addition, check the availability of all of the gateways or routers between your
domain controller and the remote one.
In addition to pinging the domain controllers, you need to ping the IP address of the DNS server. If this command
fails, verify that the DNS server is operational and the address is correct.
Per formi ng Ot her Troubl eshoot i ng Test s Usi ng Di rect oryAnal yzer
You can perform several other tests of network connectivity in AD using DirectoryAnalyzer from NetPro
Computing. You can test the network connection, view the current status and name, query IP addresses, and
perform server lookups. You can use DirectoryAnalyzer to perform the following troubleshooting tests:
Domain Controller Connectivity Test
Domain Connectivity Test
Site Connectivity Test.
Each performs a different type of connectivity test among the domain controllers in specific AD domains and sites.
Domai n Cont rol l er Connect i vi t y Test
The Domain Controller Connectivity test allows you to test the connectivity between a selected domain controller in
the forest and one or more target domain controllers. This test is useful for testing communications among any
domain controllers in the forest. To perform this test, choose Troubleshoot>DC Connectivity. The Test Domain
Controller Connectivity dialog box appears, where you can select the domain controllers involved in the test.
First, select the source domain controller from the Source list. Next, select the destination domain controller(s) that
the source will communicate with during the test by clicking the check box to the left of each domain controller in
the Destination list. Then click Start Test. Figure 5.3 shows the results of running the Domain Controller
Connectivity test.
After the test is completed, the results are displayed at the bottom of the dialog box.
Dest i nat i on
Shows the name of each destination domain controller you selected.
Test
Shows the type of test that was performed. The type of test varies according to the services that have
been assigned to the domain controller.
Ti me
Shows the amount of time (in milliseconds) it took to perform each test. If a test is performed in
less than 10 milliseconds, its displayed as < 10 ms; otherwise, the actual time is displayed.
Resul t
Shows whether a test was successful. If the test failed, this column displays a brief description of why.
Figure 5.3: Running t he Domain Cont roller Connect ivit y t est t o t roubleshoot t he communicat ion pat h among domain
cont rollers in t he forest .
Domai n Connect i vi t y Test
The Domain Connectivity test allows you to test the connectivity of a domain controller in a selected domain against
domain controllers in the destination domain(s). To perform this test, choose Troubleshoot>Domain Connectivity.
The Test Domain Connectivity dialog box appears, where you can select the domains involved in the test.
First, select the source domain/domain controller from the Source list. Next, select the destination domain(s) that
the source domain/domain controller will communicate with during the test by clicking the check box to the left
of each domain in the Destination list. Then click Start Test. Figure 5.4 shows the results of running the Domain
Connectivity test.
Dest i nat i on
Shows the name of each destination domain/domain controller you selected.
Test
Shows the type of test that was performed. The type of test varies according to the services that have
been assigned to the domain controller.
Ti me
Shows the amount of time (in milliseconds) it took to perform each test. If a test is performed in less than
10 milliseconds, its displayed as < 10 ms; otherwise, the actual time is displayed.
Resul t
Figure 5.4: Running t he Domain Connect ivit y t est t o t roubleshoot t he communicat ion bet ween t he domain cont roller in
t he source domain and t he domain cont rollers in t he dest inat ion domain.
Si t e Connect i vi t y Test
The Site Connectivity test allows you to test the connectivity of a domain controller in a selected site against domain
controllers in the destination site. To perform this test, choose Troubleshoot>Site Connectivity. The Test Site
Connectivity dialog box appears, where you can select the site and domain controllers involved in the test.
First, select the source site/domain controller from the Source list. Next, select the destination site(s) that the source
domain/domain controller will communicate with during the test by clicking the check box to the left of each name
in the Destination list. Then click Start Test. Figure 5.5 shows the results of running the Site Connectivity test.
Dest i nat i on
Shows the name of each destination site/domain controller you selected.
Test
Shows the type of test that was performed. The type of test varies according to the services that have been
assigned to the domain controller.
Ti me
Shows the amount of time (in milliseconds) it took to perform each test. If a test is performed in less than
10 milliseconds, its displayed as < 10 ms; otherwise, the actual time is displayed.
Resul t
Figure 5.5: Running t he Sit e Connect ivit y t est t o t roubleshoot t he communicat ion bet ween a sit e/ domain cont roller and
t he domain cont rollers in t he dest inat ion sit e.
Troubl eshoot i ng Name Resol ut i on
DNS is the de facto name-resolution system used to locate computers and domain controllers in AD. For example,
a workstation or member server finds a domain controller by querying DNS. If you have problems connecting to
AD and youve successfully tested network connectivity, a name-resolution problem may exist. For example, if you
cannot find domain controllers or network resources when you perform queries, it might mean that DNS domain
names arent being resolved to IP addresses.
Underst andi ng Name Resol ut i on
The first step in identifying and diagnosing AD name-resolution problems is to review how the Win2K-based
computer registers names and locates domain controllers. For example, whenever you start a Win2K domain
controller, it registers two types of names:
A DNS domain name with the DNS service
If the computer has Network Basic Input/Output System (NetBIOS) enabled, a NETBIOS name with
Windows Internet Name Service (WINS) or with another transport-specific service.
The DNS resource records (RRs) registered by the domain controllers in AD include multiple service (SRV)
records, address (A) records, and CNAME (canonical name) records, all of which identify the domain controllers
location in a domain and forest. When the domain controller is started, the Netlogon service registers these records.
It also sends DNS dynamic-update queries for the SRV records, A records, and CNAME records every hour to
ensure that the DNS server always has the proper records.
When you use AD-integrated zones, the DNS server stores all of the records in the zone in AD. To run AD-integrated
zones, the DNS service must be running on the domain controller. Its possible that a record is updated in AD but
hasnt replicated to all DNS servers loading the zone. This might cause consistency problems. By default, all DNS
servers that load zones from AD poll the directory at set intervals (every five minutes, but you can change this) to
update the directorys representation of the zones.
Checki ng That DNS Records Are Regi st ered
If DNS records arent registered on the DNS server, no other domain controller or workstation can locate the
domain controller. There are a few ways that you can check for this.
Usi ng Event Vi ewer
If DNS records arent registered in DNSfor example, if the DNS client has problems dynamically updating DNS
recordserrors are recorded in the System Log in Event Viewer. Figure 5.6 shows how the System Log tracks DNS
errors in Event Viewer.
Figure 5.6: Using Event Viewer t o t rack DNS errors t hat occur on t he select ed domain cont roller.
If the domain controller is a DNS server, an additional log tracks all of the DNS basic events and errors for the
DNS service on the server. For example, the DNS Server log monitors and tracks the starts and stops for the
DNS server. It also logs critical events, such as when the server starts but cannot locate initializing datafor example,
zones or boot information stored in the Win2K Registry or (in some cases) AD. Figure 5.7 shows how you can
access the DNS Server log in Event Viewer.
Figure 5.7: Using t he DNS Ser ver log in Event Viewer t o t rack t he errors for all DNS event s t hat occur on a domain cont roller
t hat suppor t s a DNS ser ver.
Usi ng PING
Another simple method for checking whether DNS records have been registered is to determine whether you can
look up the names and addresses of network resources using the PING utility. For example, you can check the
names using PING as follows:
PING COMPANY.COM
If this command works, the DNS server can be contacted using this basic network test.
Usi ng NSLOOKUP
Next, you need to verify that the DNS server is able to listen to and respond to basic client requests. You can do
this using NSLOOKUP, a standard command-line utility provided in most DNS-service implementations, including
Win2K. NSLOOKUP allows you to perform query testing of DNS servers and provides detailed responses as its
output. This information is useful when you troubleshoot name-resolution problems, verify that RRs are added or
updated correctly in a zone, and debug other server-related problems.
To test whether the DNS server can respond to DNS clients, use NSLOOKUP as follows:
NSLOOKUP
Once the NSLOOKUP utility loads, you can perform a test at its command prompt to check whether the host
name appears in DNS. Listing 5.2 shows entering a host name and the output you can receive:
company.com
Server: ns1.company.com
Address: 250.45.87.13
Name: company.com
Address: 250.65.123.65
The output of this command means that DNS contains the A record and the server is responding with an answer:
250.65.123.65. Next, verify whether this address is the actual IP address for your computer.
You can also use NSLOOKUP to perform DNS queries, examine the contents of zone files on the local and remote
DNS servers, and start and stop the DNS servers. If the record for the requested server isnt found in DNS, you
receive the following message:
The computer or DNS domain name does not exist
Checki ng t he Consi st ency and Proper t i es of t he DNS Server
You can check the consistency and view the properties of DNS servers, zones, and RRs using another command-line
utility called DNSCMD. Windows 2000 Server provides DNSCMD as a command-line interface for managing
DNS servers. You can use this tool to script batch files, help automate the management and updating of existing
DNS server configurations, and set up and configure new DNS servers on your network. DNSCMD also allows
you to manually modify DNS server properties, create zones and RRs, and force replication between a DNS
servers physical memory and the DNS database and data files.
You can use DNSCMD for most tasks that you can perform from the DNS console, such as:
Creating, deleting, and viewing zones and records
Resetting server and zone properties
Performing routine administrative operations, such as updating, reloading, and refreshing the zone
Writing the zone back to a file or to AD
Pausing and resuming the zone
Clearing the cache
Stopping and starting the DNS service
Viewing statistics.
You can install DNSCMD by copying it from the \Support\Tools folder located on the Windows 2000 CD-ROM.
For help in using the command, enter the following at a command prompt:
DNSCMD /?
When t he DNS Server Doesn t Resol ve Names Correct l y
Win2K includes a caching DNS-resolver service, which is enabled by default. For troubleshooting purposes, this
service can be viewed, stopped, and started like any other Win2K service. The caching resolver reduces DNS
network traffic and speeds name resolution by providing a local cache for DNS queries.
List ing 5.2: A sample command and out put received using NSLOOKUP.
How t he Cachi ng DNS-Resol ver Servi ce Works
When a name is submitted to DNS, if the resolver is caching names, it first checks the cache. If the name is in the
cache, the data is returned to the user. If the name isnt in the cache, the resolver queries the other DNS servers that
are listed in the TCP/IP properties for each adapter. It does this in the following order:
1. The resolver sends the query to the first server on the preferred adapters list of DNS servers and waits
one second for a response.
2. If the resolver doesnt receive a response from the first server within one second, it sends the query to the
first DNS servers on all adapters that are still under consideration and waits two seconds for a response.
3. If the resolver doesnt receive a response from any server within two seconds, it sends the query to all
DNS servers on all adapters that are still under consideration and waits another two seconds for a response.
4. If the resolver still doesnt receive a response from any server, it sends the query to all DNS servers on all
adapters that are still under consideration and waits four seconds for a response.
5. If it still doesnt receive a response from any server, the resolver sends the query to all DNS servers on all
adapters that are still under consideration and waits eight seconds for a response.
6. If the resolver receives a positive response, it stops querying for the name, adds the response to the cache,
and returns the response to the client. If it doesnt receive a response from any server by the end of the
eight seconds, it responds with a time-out. Also, if it doesnt receive a response from any server on a
specified adapter, it responds for the next 30 seconds to all queries destined for servers on that adapter
with a time-out and doesnt query those servers.
The resolver also keeps track of which servers answer queries more quickly, and it might move servers up or down
on the search list based on how quickly they respond.
Usi ng Ot her Techni ques
A typical problem occurs when a DNS server doesnt resolve names correctly and provides incorrect data for
queries. For example, if an administrator changed the IP address on a domain controller but DNS wasnt properly
updated, DNS would supply the incorrect IP address to clients.
When working with Windows 2000 Server and DNS entry changes, you may notice that the DNS server has stale
RRs because they havent been updated recently. This means that if there have been previous lookups or name-resolution
activity, the DNS server doesnt see the changes to the RRs. (The server caches DNS information from previous
lookups so that subsequent lookups are fast.) The typical method of fixing this problem is to restart the server.
You can also fix this problem using the IPCONFIG command. Entering the following command allows you to
view the current list of DNS entries that the server has cached:
IPCONFIG /displayDNS
Entering the following command allows you to refresh all DHCP leases and re-register DNS names. (Wait five
minutes for the DNS entries in the cache to be reset and updated with the RRs in the servers database.)
IPCONFIG /registerDNS
You can also use the IPCONFIG command to dump all of the DNS cache entries.
IPCONFIG /flushDNS
Its worth noting that the DNS server should eventually refresh the cache because each entry has a Time-To-Live
(TTL) associated with it. TTL indicates a length of time used by other DNS servers to determine how long to
cache information for a record before discarding it. For example, most RRs created by the DNS Server service
inherit the minimum (default) TTL of 1 hour from the start-of-authority (SOA) RR; this prevents overly long
caching by other DNS servers. TTL is automatically decremented and eventually expires and disappears or is
flushed from the cache.
For an individual RR, you can specify a record-specific TTL that overrides the minimum (default) TTL inherited
from the SOA RR. You can also use TTL values of zero (0) for RRs that contain volatile data not to be cached for
later use after the current DNS query is completed.
Another problem that may occur is that the DNS server doesnt resolve names for computers or services outside
your immediate network. For example, the DNS server may not resolve names for computers located on an external
network or the Internet. If a DNS server fails to resolve a name for which its not authoritative, the cause is usually
a failed recursive query. Recursion is used in most DNS configurations to resolve names that arent located in the
configured DNS domain.
For recursion to work correctly, all DNS servers used in the path of the recursive query must be able to respond to
and forward correct data. If the DNS server fails a recursive query, you need to review the servers configuration.
By default, all Win2K DNS servers have recursion enabled. You can disable recursion using the DNS console to modify
advanced server options. In addition, recursion might be disabled if the DNS server is configured to use forwarders.
Troubl eshoot i ng t he Domai n Cont rol l ers
You have a number of options for troubleshooting domain controllers. Before I discuss them, though, its important
to review the AD database and its associated files.
Underst andi ng t he Act i ve Di rect ory Dat abase and It s Associ at ed Fi l es
AD is stored on each domain controller in a local database. The database exists as a domain database and, married
with the directory services, performs authentication services to users and applications. The domain controllers
replicate their data with each other to ensure that copies of the domain database on other domain controllers are
current and accurate.
The AD database is implemented on an indexed sequential access method (ISAM) table manager that has been
referred to as "Jet." The table manager is called the Extensible Storage Engine (ESE). The ESE database is managed
on each domain controller by the ESE.DLL file. The database is a discrete transaction system that uses log files to
ensure integrity; it uses support rollback to ensure that the transactions are committed to the database.
The following files are associated with AD:
NTDS.DIT
The main database file; it grows as the database fills with objects and attributes. On the other hand, the log
files have a fixed size of 10 megabytes (MB). Any changes made to the database are also made to the current
log file and to the DIT file in the cache. Eventually the cache is flushed. If a computer failure occurs before
the cache is flushed, ESE uses the log file to complete the update to the DIT file.
By default, the AD database is stored in <DRIVE>\WINNT\NTDS\NTDS.DIT. The log files for the
directory database are stored in the same directory by default. Their purpose is to track the changes in the
directory database, and they can grow to be quite large. I recommend that you give all the room you can to
the log files. For example, you can place the log files on different disk drives than the database file to reduce
disk contention on a single drive.
EDB.LOG and EDBXXXXX.LOG
EDB.LOG is the current log file for AD. When a change is made to the database, its written to this file.
When EDB.LOG becomes full of database transactions, its renamed to EDBXXXXX.LOG, where XXXXX
starts at 00001 and continues to increment using hexadecimal notation. AD uses circular logging, which
constantly deletes old log files. If you view the directory files at any time, youll notice the EDB.LOG file
and at least one or more EDBXXXXX.LOG files.
EDB.CHK
Stores the database checkpoint, which identifies the point where the database engine needs to
replay the logs. This file is typically used during recovery and initialization.
RES1.LOG and RES2.LOG
Placeholders designed to reserve the last 20MB of disk space on the disk drive. Saving disk space gives the
log files sufficient room to shut down gracefully if other disk space is consumed.
To manage the database, Win2K provides a garbage-collection process designed to free space in the AD database.
This process runs on every domain controller in the enterprise with a default lifetime interval of 12 hours. The
garbage-collection process first removes "tombstones" from the database. Tombstones are remains of objects that
have been deleted. (When an object is deleted, its not actually removed from the AD database. Instead, its marked
for deletion at a later date. This information is then replicated to other domain controllers. When the time expires
for the object, the object is deleted.) Next, the garbage collection-process deletes any unnecessary log files. Finally, it
launches a defragmentation thread to claim additional free space.
Above the directory database is a database layer that provides an object view of the database information by applying
the schema to the database records. The database layer isolates the upper logical layers of the directory from the
underlying database system. All access to the database occurs through this layer instead of allowing direct access to
the database files. The database layer is responsible for creating, retrieving, and deleting the individual database
records or objects and associated attributes and values.
In addition to the database layer, AD provides a directory service agent (DSA), an internal process in Win2K that
manages the interaction with the database layer for the directory. AD provides access using the following protocols:
Lightweight Directory Access Protocol (LDAP) clients connect to the DSA using the LDAP protocol
Messaging Application Programming Interface (MAPI) clients connect to the directory through the DSA
using the MAPI remote procedure call (RPC) interface
Windows clients that use Windows NT 4.0 or earlier connect to the DSA using the Security Account
Manager (SAM) interface
AD domain controllers connect to each other during replication using the DSA and a proprietary RPC
implementation.
Compari ng Di rect ory Informat i on
When you want to compare directory information on domain controllers or directory partitions, you can use the
DSASTAT utility. DSASTAT detects and examines the differences among a user-defined scope of objects on two
different domain controllers. It retrieves capacity statistics such as megabytes per server, objects per server, and
megabytes per object class. For example, you can use DSASTAT to compare all users in the SALES Organizational
Unit (OU) in the COMPANY.COM domain with those in another directory partition by specifying the following:
DSASTAT -S:Company1;Company2 -B:OU=SALES,DC=COMPANY,DC=COM -
GCATTRS:ALL -SORT:TRUE -T:FALSE -P:16 -FILTER:
"(&(OBJECTCLASS=USER)(!OBJECTCLASS=COMPUTER))"
In this example, you can determine whether both domain controllers agree on the contents of the
OU=SALES,DC=COMPANY,DC=COM subtree. DSASTAT detects objects in one domain and not the other
(for example, if a creation or deletion hasnt replicated) as well as differences in the values of objects that exist in
both. This example specifies a base search path at a subtree of the domain. In this case, the OU name is SALES.
The filter specifies that the comparison is concerned only with user objects, not computer objects. Because computer
objects are derived from user objects in the class hierarchy, a search filter specifying OBJECTCLASS = USER
returns both user and computer objects.
DSASTAT also allows you to specify the target domain controllers and additional operational parameters using the
command line or an initialization file. DSASTAT determines whether domain controllers in a domain have a
consistent and accurate image of their own domain.
DSASTAT also compares the attributes of replicated objects. You can use it to compare two directory trees across
replicas in the same domain or, in the case of a Global Catalog (GC), across different domains. You can also use
it to monitor replication status at a much higher level than monitoring detailed transactions. In the case of GCs,
DSASTAT checks whether the GC server has an image that is consistent with the domain controllers in other
domains. DSASTAT complements the other replication-monitoring tools, REPADMIN and REPLMON, by
ensuring that domain controllers are up to date with one another.
Anal yzi ng t he St at e of t he Domai n Cont rol l ers
The first step in troubleshooting and repairing problems with AD on the domain controller is to verify that the
directory portion is running without errors. The Domain Controller Diagnostic (DCDIAG) utility allows you to
analyze the current state of the domain controllers in a domain or forest. It automatically performs the analysis and
reports any problems with a domain controller. DCDIAG requires a separate installation of the Support Tools from
the Windows 2000 Server or Advanced Server CD-ROM; by default, its installed in \program files\support tools.
DCDIAG is int ended t o per form a fully aut omat ic analysis wit h lit t le user int er vent ion. This means t hat you
usually don t need t o provide t oo many paramet ers t o it on t he command line. DCDIAG doesn t work when
run against a Win2K workst at ion or ser ver, and it s limit ed t o working only wit h domain cont rollers.
DCDIAG consists of a set of tests that you can use to verify and report on the functional components of AD on the
computer. You can use this tool on a single domain controller, a group of domain controllers holding a domain partition,
or across a site. When using DCDIAG, you can collect either a minimal amount of information (confirmation of
successful tests) or data for every test you execute. Unless youre diagnosing a specific problem on only one domain
controller, I recommend that you collect only the severe errors for each one.
DCDIAG allows you to run the following tests to diagnose the status of a domain controller:
Connect i vi t y Test
Verifies that DNS names for the domain controller are registered. It also verifies that the domain controller
can be reached using TCP/IP and the domain controllers IP address. DCDIAG checks the connectivity to
the domain controller using LDAP and checks that communications can occur using an RPC.
Repl i cat i on Test
Checks the replication consistency for each of the target domain controllers. For example, this test checks
whether replication is disabled and whether replication is taking too long. If so, the utility reports these
replication errors and generates errors when there are problems with incoming replica links.
Topol ogy Int egri t y Test
Verifies that all domain controllers holding a specific partition are connected by the replication topology.
Di rect ory Par t i t i on Head Permi ssi ons Test
Checks the security descriptors for proper permissions on the directory partition heads, such as the schema,
domain, and configuration directory partitions.
Locat or Funct i onal i t y Test
Verifies that the appropriate SRV RRs are published in DNS. This test also verifies that the domain
controller can recognize and communicate with operations masters. For example, DCDIAG checks whether
the locator can find a primary domain controller (PDC) and GC server.
Int er-si t e Heal t h Test
Identifies and ensures the consistency of domain controllers among sites. To do this, DCDIAG performs
several tests, one of which identifies the inter-site topology generator and identifies the bridgeheads for each
site. This test determines whether a bridgehead server is functioning; if not, the utility identifies and locates
additional backup bridgeheads. In addition, this test identifies when sites arent communicating with other
sites on the network.
Trust Veri fi cat i on Test
Checks explicit trust relationshipsthat is, trusts between two domain controllers in the forest. DCDIAG
cannot check transitive trusts (Kerberos V5 trust relationships). To check transitive trusts, you can use the
Windows 2000 Resource Kits NETDOM utility (not described in this chapter).
For more informat ion on t he Windows 2000 Resource Kit s NETDOM ut ilit y, refer t o t he Resource Kit
document at ion or The Defi ni t i ve Gui de t o Wi ndows 2000 and Exchange 2000 Mi grat i on
(Realt imepublishers), a link t o which can be found at ht t p:/ / www.realt imepublishers.com.
Di agnose Repl i cat i on Lat enci es Test
Analyzes incoming replications and watches for delays or preemption of a higher-priority job. If the
replication process is delayed or preempted, latencies have occurred that slow down the process. This
problem typically occurs because a higher-priority task hasnt relinquished the computers processor or
because a large number of replication requests or tasks is pending. New replication tasks are delayed
because the domain controller is overloaded with replication requests.
Repl i cat i on of Trust Obj ect s Test
Checks whether the computer account object has been replicated to all additional domain controllers in
the domain. It also checks whether the DSA object has been replicated to all replicas of the configuration
directory partition.
Fi l e Repl i cat i on Servi ce (FRS) Test
Verifies that FRS has started successfully on all domain controllers. If it hasnt, this test delays the
NETLOGON service from advertising that domain controller.
Cri t i cal Servi ces Check Test
Verifies that these key services are running: FRS, Inter-site Messaging Service, Kerberos Key Distribution
Center Service, Server Service, Workstation Service, Remote Procedure Call Locator Service, Windows
Time Service, Distributed Link Tracking Client Service, Distributed Link Tracking Server Service, and
NETLOGON service. You can also use DCDIAG with the /repairmachineaccount command-line switch,
which re-creates the domain controllers machine account if its been accidentally deleted.
Usi ng NTDSUTIL
The Directory Services Management utility (NTDSUTIL.EXE) is a command-line utility included in Win2K that
you can use to troubleshoot and repair AD. Although Microsoft designed NTDSUTIL to be used interactively via
a command-prompt session (launched simply by typing NTDSUTIL at any command prompt), you can also run
it using scripting and automation. NTDSUTIL allows you to troubleshoot and maintain various internal components
of AD. For example, you can manage the directory store or database and clean up orphaned data objects that were
improperly removed.
You can also maintain the directory service database, prepare for new domain creations, manage the control of the
Flexible Single Master Operations (FSMOs), purge metadata left behind by abandoned domain controllers (those
removed from the forest without being uninstalled), and clean up objects and attributes of decommissioned or
demoted servers. At each NTDSUTIL menu, you can type help for more information about the available options.
(See Figure 5.8.)
Figure 5.8: Viewing a list of available commands in t he ut ilit y and a brief descript ion of each.
Locat i ng t he Di rect ory Dat abase Fi l es
Before you use the NTDSUTIL utility to carry out troubleshooting and integrity checking on the AD database,
you can use its Info command to determine the location and size of the directory database files. The Info command:
Reports the free space for all disks installed on the domain controller
Reads the Registry keys and associated location of the AD database files
Reports the size of each of the database files, log files, and other associated files.
Before you perform this check, you have to either run NTDSUTIL after having booted the domain controller via
the special Directory Service Restore Mode mode Safe Boot option or set the environment variable
SAFEBOOT_OPTION to a value of DSREPAIR under a normal boot of Windows 2000 (e.g. via the command
SET SAFEBOOT_OPTION=DSREPAIR).
To execute the Info command:
1. Choose Start>Programs>Accessories>Command Prompt.
2. In the Command Prompt window, type NTDSUTIL, then press Enter.
3. At the ntdsutil: prompt, enter the word files. The utility responds by displaying a file maintenance prompt.
The following commands have been entered and displayed to this point:
C:\>SET SAFEBOOT_OPTION=DSREPAIR
C:\>NTDSUTIL
ntdsutil: files
file maintenance:
4. At the File Maintenance prompt, enter the word info to display the location and sizes of AD database
files, log files, and other associated files.
Figure 5.9: Using t he Info command in NTDSUTIL t o display t he locat ion and size of AD dat abase files.
Figure 5.9 shows the output of this command on a domain controller.
Checki ng for Low-Level Dat abase Corrupt i on
One of the first items you need to check when troubleshooting a domain controller in AD is that the underlying
database is functioning properly. To do this, you can use NTDSUTILs Integrity option to detect any low-level
database corruption of the directory files. The Integrity option checks that the headers for the database itself are
correct and that all of the internal database tables are functioning and consistent with each other.
Before you perform a low-level database-integrity check, you need to start the domain controller in Directory
Service Restore mode. To do this:
1. Restart the domain controller. When youre prompted, press F8 to display the Windows 2000
Advanced Option menu.
2. Select Directory Service Restore Mode and press Enter.
3. Log on using the Administrator account and password that you assigned during the DCPROMO
process.
Using NTDSUTIL, you can relocat e or move AD dat abase files from one locat ion t o anot her on t he disk or
move t he dat abase files from one disk drive t o anot her in t he same domain cont roller. You can also move
just t he log files from one disk t o anot her t o free up space for t he dat a files. (See " Moving t he Act ive
Direct or y Dat abase or Log Files" lat er in t his chapt er.)
To run the NTDSUTIL Integrity option:
3. At the ntdsutil: prompt, enter the word files. The utility responds by showing you the File Maintenance
category.
The commands to this point appear in the Command Prompt window as follows:
I:>NTDSUTIL
ntdsutil: files
file maintenance:
4. At the File Maintenance prompt, enter the word integrity to start the low-level database check on the
domain controller. (The Integrity command reads every byte of the directory data file and displays the
percentage of completion as a graph. Depending on the size of your database and the type of hardware
youre using for the domain controller, this process can take a considerable amount of time.)
Figure 5.10 shows the results of examining the low-level database structures in AD.
Figure 5.10: Using t he Int egrit y opt ion in NTDSUTIL t o examine t he AD dat abase on a domain cont roller.
Checki ng for Inconsi st enci es i n t he Dat abase Cont ent s
In addition to using NTDSUTIL to verify that the AD database is functioning properly, you can use it to help you
check the consistency of the contents of the AD database. The option in NTDSUTIL that performs a contents
check is the Semantic Checker. The Semantic Checker option differs from the Integrity option in that it addresses
the contents (objects and attributes) of the directory database, not just its low-level structures.
When you run the Semantic Checker, it performs the following checks:
Reference Count Check
Counts the number of references in the database tables and matches the results with the values that are
stored in the data file. This operation also ensures that each object has a globally unique identifier (GUID)
and distinguished name (DN). For a previously deleted object, this operation ensures that the object has a
deleted time and date but doesnt have a GUID or DN.
Del et ed Obj ect Check
Ensures that the object has a time and date as well as a special relative distinguished name (RDN), given
when the object was originally deleted.
Ancest or Check
Ensures that the DN tag is equal to the ancestor list of the parent. This could also be stated as a check that
the distinguished name of the object minus its RDN is equal to its parents DN.
Securi t y Descri pt or Check
Ensures that there is a valid descriptor and that the discretionary access control list (DACL) isnt empty.
Repl i cat i on Check
Verifies that there is an up-to-dateness vector in the directory partition and checks to see that every object
has metadata.
Like the Integrity option described above, you can run the Semantic Checker option only when the domain
controller is in Directory Service Restore mode. To run in this mode:
1. Restart the domain controller. When youre prompted, press F8 to display the Windows 2000
Advanced Option menu.
3. Log on using the administrator account and password that you assigned during the DCPROMO process.
To troubleshoot and repair the AD database, you can use the Integrity option only while the domain controller
is in Direct or y Ser vice Rest ore mode.
To run the Semantic Checker option:
3. At the ntdsutil: prompt, type semantic database analysis, then press Enter.
4. Type verbose on. This displays the Semantic Checker.
5. To start the Semantic Checker without having it repair any errors, type go. To start it and have it repair
any errors that it encounters in the database, enter go fixup.
The commands to this point appear in the Command Prompt window as follows:
I:>NTDSUTIL
ntdsutil: semantic database analysis
semantic checker: verbose on
Verbose mode enabled.
semantic checker: go
Figure 5.11 shows the results of using the NTDSUTIL Semantic Checker.
Figure 5.11: Using t he NTDSUTIL Semant ic Checker opt ion t o check t he consist ency of t he cont ent s of t he direct or y dat abase.
Cl eani ng Up t he Met adat a
The NTDSUTIL program allows you to clean up the metadata that is left behind after a domain controller is
demoted. The utility that you use to demote a domain controller is the DCPROMO utility (DCPROMO.EXE).
This utility is used to promote a server to a domain controller and demote a domain controller to a member server.
As part of the demotion process, DCPROMO removes the configuration data for the domain controller from AD.
This data takes the form of an NTDS Settings object, which exists as a child to the server object in the Active
Directory Sites and Services Manager and is located in AD as the following object:
CN=NTDS
Settings,CN=<server_name>,CN=Servers,CN=<site_name>,CN=Sites,
CN=Configuration,DC=<domain>...
The attributes of the NTDS Settings object contain values about the domain controllers replication partners,
naming contexts, whether the domain controller is a GC server, and the default query policy. The NTDS Settings
object is also a container that may have child objects that represent the replication partners. This data is required
for the domain controller to synchronize quickly but is retired upon demotion. If the NTDS Settings object isnt
properly removed when the domain controller is demoted, you can use the NTDSUTIL utility to manually remove
the NTDS Settings object.
To clean up the metadata:
2. At the command prompt, type NTDSUTIL, then press Enter.
3. At the ntdsutil prompt, type metadata cleanup, then press Enter. Based on the options returned to the
screen, you can use additional configuration parameters to ensure that the removal occurs correctly.
4. Before you clean up the metadata, you must select the server on which you want to make the changes.
To connect to a target server, type connections, then press Enter.
5. If the user who is currently logged on to the computer running NTDSUTIL doesnt have administrative
permissions on the target server, alternate credentials need to be supplied before making the connection.
To supply alternate credentials, type the following command, then press Enter:
set creds <domain_name user_name password>
6. Type connect to server <server_name>, then press Enter. You should receive confirmation that the
connection has been successfully established. If an error occurs, verify that the domain controller you
specified is available and that the credentials you supplied have administrative permissions on the server.
7. When a connection has been established and youve provided the right credentials, type quit, then press
Enter, to exit the Connections menu in NTDSUTIL.
8. When the Metadata Cleanup menu is displayed, type select operation target and press Enter.
9. Type list domains, then press Enter. A list of domains in the forest is displayed, each with an associated
number. To select the appropriate domain, type select domain <number>and press Enter (where <number> is
the number associated with the domain of which the domain controller youre removing is a member).
The domain you select determines whether the server being removed is the last domain controller of
that domain.
10. Type list sites, then press Enter. A list of sites, each with an associated number, is displayed.
Before you manually remove t he NTDS Set t ings object for any ser ver, check t hat replicat ion has occurred
aft er t he domain cont roller has been demot ed. Using t he NTDSUTIL ut ilit y improperly can result in par t ial
or complet e loss of AD funct ionalit y. (For a descript ion of how t o check whet her replicat ion has occurred,
see Chapt er 4.)
11. Type select site <number> and press Enter (where <number> is the number associated with the site of
which the server youre removing is a member). You should receive a confirmation, listing the site and
domain you chose.
12. Type list servers in site and press Enter. A list of servers in the site, each with an associated number, is
displayed.
13. Type select server <number> and press Enter (where <number> is the number associated with the server
you want to remove). You receive a confirmation, listing the selected server, its DNS host name, and
the location of the servers computer account that you want to remove.
14. After youve selected the proper domain and server, type quit to exit the current NTDSUTIL sub
menu. When the Metadata Cleanup menu is displayed, type remove selected server and press Enter.
You should receive confirmation that the server was removed successfully. If the NTDS Settings object
has already been removed, you may receive the following error message:
Error 8419 (0x20E3)
The DSA object couldnt be found
15. Type quit at each menu to quit the NTDSUTIL utility. You should receive confirmation that the
connection disconnected successfully.
Movi ng t he Act i ve Di rect ory Dat abase or Log Fi l es
There are several common problems that occur with AD that all stem from the same source: low disk space. These
problems may surface as any of a number of errors messages in the Win2K Event Log. The most common of these
errors is described below, along with their associated symptoms and solutions.
The following error message may occur when you start AD on a domain controller:
Lsass.exe - System Error
Directory Services could not start because of the following error: There is
not enough space on the disk.Error Status: 0xc000007f. Please click OK to
shutdown this system and reboot into Directory Service Restore Mode, check the
event logs for more detailed information.
When this error occurs, the following events are recorded in the Event Log for the directory service
on the domain controller and can be viewed using Event Viewer:
Event ID: 1393
Attempts to update the Directory Service database are failing with error
112.Since Windows will be unable to log on users while this condition persists,
the Netlogon service is being paused. Check to make sure that adequate free
disk space is available on the drives where the directory database and log
files reside.
Event ID: 428
NTDS (272) The database engine is rejecting update operations due to low
free disk space on the log disk.
The following warning message is recorded in the System Log of the domain controller and can be viewed
using Event Viewer:
Event ID 2013:
The D: disk is nearing Capacity. You may need to delete some files.
If the disk drive runs out of disk space, AD wont start up. Win2K attempts to avoid this situation, but it can occur
if you ignore warnings about low disk space in the System Log or if you run large scripts against AD for mass
directory imports.
To resolve the problem of having no disk space, you can either make space available on the same disk drive or
move AD to a separate drive. The first method requires you to simply reduce the number of files or folders on the
same disk drive as the directory database.
If you want to move the AD database to another drive on the domain controller, you can use the NTDSUTIL utility
to move either the database file or the database log files. This method is ideal when you cannot move data to
another drive to free up space. If all drives are at capacity, you may need to install an additional hard disk in the
domain controller.
Before you move the directory database file or log files, you need to start the domain controller in Directory
Service Restore mode. To do this:
1. Restart the domain controller. When youre prompted, press F8 to display the Windows 2000 Advanced
Option menu.
3. Log on using the administrator account and password that you assigned during the DCPROMO process.
To move the directory database file or log files:
1. Locate the drive containing the directory and log files. The directory database (NTDS.DIT) and log files
are located in the NTDS folder on the root drive by default. (However, the administrator may have
changed their locations during the DCPROMO process.)
4. At the ntdsutil: prompt, enter the word files. The utility displays the File Maintenance category.
The commands to this point should appear as follows:
I:>NTDSUTIL
ntdsutil: files
file maintenance:
5. At the File Maintenance prompt, enter the word info to display the location of the AD database files, log
files, and other associated files. Note the location of the database and log files.
6. To move the database files to a target disk drive, type the following command at the ntdsutil: prompt:
MOVE DB TO %s (where %s is the target folder on another drive)
7. To move the log files to a target disk drive, type the following command at the ntdsutil: prompt. (The
target directory where you move the database file or log files is specified by the %s parameter. The Move
command moves the files and updates the Registry keys on the domain controller so that AD restarts
using the new location.)
MOVE LOGS TO %s (where %s is the target folder on another drive)
8. To quit NTDSUTIL, type quit twice to return to the Win2K command prompt, then restart the
domain controller normally.
Repai ri ng t he Act i ve Di rect ory Dat abase
You can use the NTDSUTIL Repair feature to repair the AD database file. However, you should use it only as a
last resort for recovering the databaseif a valid backup is available, always use it first to restore the data. The reason
is that repairing the directory database doesnt always work correctly. For example, if a database file is corrupt, using
the NTDSUTIL Repair feature may not restore all objects and attributes. In fact, in some cases, there is a risk that
using the Repair feature will cause further data to be lost.
To repair the AD database file:
3. At the ntdsutil: prompt, enter the word files. The utility displays the File Maintenance category.
4. At the File Maintenance prompt, enter the word repair.
The commands to this point should appear as follows:
I:>NTDSUTIL
ntdsutil: files
file maintenance: repair
5. As soon as the repair operation has completed, run the NTDSUTIL Semantic Checker on the database.
(For instructions, see "Cleaning Up the Metadata" earlier in this chapter.)
I highly recommend t hat you complet ely back up AD on t he domain cont roller before you execut e t he Move
command. In addit ion, I recommend t hat you back up AD aft er you move t he direct or y dat abase file and
log files; rest oring t he direct or y dat abase will t hen ret ain t he new file locat ion.
Figure 5.12 shows the results of using the NTDSUTIL Repair option.
Figure 5.12: Using NTDSUTIL as a last resor t t o repair t he direct or y dat abase files.
Troubl eshoot i ng Secure Channel s and Trust Rel at i onshi ps
When a Win2K system joins a domain, a computer account is created. Whenever the system starts after that, it
uses the password for that account to create a secure channel with the domain controller for its domain. Requests
sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the
channel isnt integrity-checked, and not all information is encrypted.
There are many reasons why a domain controller cannot communicate on a secure channel. For example, the user
or domain controller may not have the appropriate access permissions or trust relationships. You can test the status
of secure channels and trust-relationship links using the Windows 2000 Resource Kits NLTEST command-line utility.
ADcheck: A Free AD and Windows 2000 Net work Diagnost ic Tool
Although Win2K and the Windows 2000 Resource Kit provide some basic tools for per forming troubleshooting
t asks, t hey aren t especially easy t o use. Net IQ Corporat ion provides an excellent and freeut ilit y for
per forming a host of AD diagnost ic and t roubleshoot ing t asks. ADcheck provides five essent ial cat egories
of Win2K diagnost ics:
1. Test Domain Cont roller
Checks t he availabilit y of t he domain cont roller, validat es DNS records (for example, SRV RRs),
and binds t o t he domain cont roller t o verify AD st at us
2. List Domain Cont rollers
List s each domain cont roller along wit h it s name, availabilit y, Act ive Direct or y Ser vice
Int er faces (ADSI) script ing locat ion, and sit e locat ion
3. List Operat ions Mast ers
List s FSMO role holders, compares t hem t o an int ernal best pract ices list , and recommends
changes when necessar y
4. Test Replicat ion
Checks domain replication topology and displays diagnostic information about replication par tners
5. Show Domain Cont roller St at us
Provides summaries of the status of domain controllers, including replication errors and par tners,
AD sit e analysis, and char t s t hat show recommended changes t o t he placement of domain
cont rollers.
ADcheck is also capable of generat ing some ver y det ailed repor t s, each of which shows pot ent ial causes
for problems as well as the problems themselves. For some repor ts, it also compares the current configuration
t o an int ernal best pract ices guideline and may recommend changes. Given t hat it s complet ely free, t his
t ool is somet hing t hat no Win2K net work administ rat or should be wit hout . You can download ADcheck
from ht t p:/ / www.net iq.com/ adcheck/ download.asp.
To validate access to resources in a trusting domain, the trusting domain controller establishes a secure channel
with a domain controller in the trusted domain. Pass-through authentication then occurs over this secure channel.
However, in WAN environments, the trusted domains domain controllers may be dispersed over a wide variety of
fast and slow links. If a fast link is unavailable when the trusting domain controller wants to establish a secure
channel, the secure channel may be established with a domain controller over a slow link. Even when the fast link
is reestablished, pass-through authentication may occur over the slow link to the trusted domains domain controller.
The mechanism for establishing a secure channel is very similar to the normal user-logon process. That is, the trusting
domain controllers send out logon requests to all known domain controllers in the trusted domain. The trusting
domain controllers then set up a secure channel with the first trusted domain controller that responds to this request.
Normally, this method is preferred because the first domain controller to respond to a logon request is typically the
controller that is located across the fastest communication link. However, if that link is down or the "fast" domain
controller is unavailable, a domain controller over a slower link may respond first, and all pass-through authentications
occur over the slow link.
There is a built-in mechanism in Windows 2000 that tracks how long authentication takes over the existing secure
channel. If pass-through authentication takes longer than 45 seconds, that fact is noted. If two such authentications
exceed that limit, a rediscovery process begins, the current secure channel is broken, and the trusting domains PDC
once again sends out logon requests to all known trusted domain controllers. However, because this mechanism
tracks only those communications that take longer than 45 seconds, users may see a 40-second delay every time
they attempt to use a resource without a secure-channel reset taking place.
You can run the NLTEST utility on the trusting domain controller to break and re-initialize a secure channel (for
example, when the secure-channel password was last changed) and obtain information about an existing trust
relationship. You can also use NLTEST to restart the discovery process for a new trusted domain controller. The
syntax of NLTEST is:
NLTEST /sc_query:<account_domain>
Where <account_domain> is the name of the trusted domain. This command returns the name of the trusted
domain controller with which the trusting domain controller has a secure channel. If that domain controller is
unacceptable, use the following syntax:
NLTEST /sc_reset:<account_domain>
Troubl eshoot i ng t he Operat i ons Mast ers
The operations masters in AD perform single-master operations for the forest and domains and are officially called
Flexible Single Master Operations, or FSMOs. A number of operations in the directory have single-master opera-
tionsoperations such as updating the schema, creating new domains in a forest, issuing new blocks of relative
IDs (RIDs), and supporting domains and clients that are running Windows NT 4.0 and earlier.
The forest has two operations masters that manage certain forest-wide single-operation activities, and each domain
has three operations masters that manage certain domain-wide activities. For example, a forest with two domains
would have eight operations masters: two for the forest and three domain-specific operations master roles in each
domain. The five FSMO roles are:
Schema masterForest-wide and one per forest
Domain Naming masterForest-wide and one per forest
Relative ID masterDomain-specific and one for each domain
Primary Domain Controller emulatorDomain-specific and one for each domain
Infrastructure masterDomain-specific and one for each domain.
Because the operations masters are assigned to specific domain controllers in the forest and domains and are critical
to the operation of AD, your first step to troubleshoot each operations master is to use the domain-controller
troubleshooting techniques described in "Troubleshooting the Domain Controllers" earlier in this chapter. Once
youre assured that the domain controller itself is operating properly, you can turn your attention to the operations masters.
When Operat i ons Mast ers Fai l
If a domain controller holding a FSMO (operations role) master fails, major network problems are almost guaranteed to
ensue. A list of the various operations master roles, their functions, and the effects of losing them are listed below:
Schema Mast er
If the domain controller holding the forest-wide schema master role fails, you or your directory administrators wont
be able to modify or extend the AD schema. Schema modifications typically occur when you install directory-enabled
applications such as management utilities that rely on the directory for information. These applications try to modify
or extend the current schema with new object classes, objects, and attributes. If the applications being installed cannot
communicate with the domain controller that has been designated as the schema master, installation will fail.
The schema master solely controls the management of the directory schema and propagates updates to the schema
to the other domain controllers as modifications occur. Because only directory administrators are allowed to make
changes, the schema operations master isnt visible to directory users and doesnt affect them.
Domai n Nami ng Mast er
If the domain naming master role holder in a forest fails, you lose the functionality of adding and removing
domains in the forest. When a new domain is created or deleted from the forest structure, the domain controller
that has been designated as the domain naming master is contacted and verifies that the change operation can be
completed.
The domain naming master is the only domain controller that controls the creation and deletion of domains, and
it propagates the changes to the other domain controllers as necessary. Because only directory administrators are
allowed to make structural domain changes to the forest, the domain naming operations master isnt visible to
directory users and doesnt affect them.
Rel at i ve ID (RID) Mast er
If the domain controller that stores the relative ID (RID) master role fails or stops communicating, domain controllers
in the same domain cannot obtain the RIDs they need. (RIDs are unique security IDs.) Domain controllers use
RIDs when they create users, groups, computers, printers, and other objects in the domain; each object is assigned
a RID. The RID master role allocates blocks of RIDs to other domain controllers in its domain. As I mentioned at
the beginning of this section, there is only one RID master role per domain.
If a domain cont roller has remaining (unassigned) RIDs in it s allocat ed block, t he RID mast er role doesn t
need t o be available when new object account s are creat ed.
Infrast ruct ure Mast er
If the domain controller that stores the infrastructure master role fails, a portion of AD wont function properly. The
infrastructure master role controls and manages the updates to all cross-domain references, such as group references
and security identifier (SID) entries in access control lists (ACLs). For example, when you add, delete, or rename a
user who is a member of a group, the infrastructure master controls the reference updates. There is always only one
infrastructure master role in each domain in a forest.
Because only one domain controller is assigned to perform this role, its important that it doesnt fail. However, if
it does, its not visible to network users. In fact, its visible to only directory administrators when theyve recently
moved or renamed a large number of object accounts. In addition, having one domain controller assigned to this
role can be a big security problem.
If you force a t ransfer of t he infrast ruct ure mast er role from it s original domain cont roller t o anot her domain
cont roller in t he same domain, you can t ransfer t he role back t o t he original domain cont roller aft er you ve
ret urned it t o product ion.
It is st rongly recommended t hat you not put t he infrast ruct ure mast er role on any domain cont roller t hat is
also act ing as a global cat alog ser ver. For more informat ion about FSMO placement rules and best pract ices,
see Microsoft Product Suppor t Ser vices ar t icle Q223346, at ht t p:/ / suppor t .microsoft .com.
PDC Emul at or
If the PDC fails or no longer communicates, users who depend on its service are affected. These are down-level
users from Window 95, Windows 98, and Windows NT 4.0 (or earlier). The PDC is responsible for changes to
the SAM database, changing passwords, account lockout for down-level workstations, and communications with
the domain controllers.
If you force a t ransfer of t he PDC emulat or role from it s original domain cont roller t o anot her domain
cont roller in t he same domain, you can t ransfer t he role back t o t he original domain cont roller aft er
you ve ret urned it t o product ion.
Det ermi ni ng t he Operat i ons Mast er Rol e Hol ders Locat i ons
An important step in the process of troubleshooting problems with operations master role holders is identifying
which domains controllers hold the various forest- and domain-wide roles. There are actually several methods of
determining the location of FSMO role holder in Win2K.
Usi ng t he DSA and Schema MMC Snap-Ins
To determine the RID, PDC, and Infrastructure FSMO Holders of a selected domain using Win2Ks built-in tools,
follow these steps:
1. Click Start, Run, type dsa.msc, and press Enter or click OK.
2. Right-click the selected Domain Object in the top left pane, and then click Operations Masters.
3. Click the PDC tab to view the server holding the PDC master role.
4. Click the Infrastructure tab to view the server holding the Infrastructure master role.
5. Click the RID Pool tab to view the server holding the RID master role.
Determining the forest Schema Master role holder is a bit trickier, and involves the following:
1. Click Start, click Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Schema,
click Close, and then click OK.
3. Right-click Active Directory Schema in the top left pane, and then click Operations Masters to view the
server holding the schema master role.
For t he Act ive Direct or y Schema snap-in t o be list ed as an available choice in St ep 2, you ll have t o have
already regist ered t he Schmmgmt .dll file. If it doesn t appear as an opt ion, follow t hese st eps t o regist er
it : click Star t, Run, type regsvr32 schmmgmt.dll in the Open box, and click OK. A message will be displayed
confirming t hat t he regist rat ion was successful.
Determining the forests Domain Naming Master role holder requires the following steps:
1. Click Start, Run, type mmc, and then click OK.
2. On the Console menu, click Add/Remove Snap-in, click Add, double-click Active Directory Domains
and Trusts, click Close, and then click OK.
3. In the left pane, click Active Directory Domains and Trusts.
4. Right-click Active Directory Domains and Trust, and click Operations Master to view the server holding
the domain naming master role in the Forest.
Although the above methods certainly work, they arent necessarily the easiest. The following sections describe
some additional methods for determining FSMO role holders on your network.
Usi ng NTDSUTIL
NTDSUTIL is a tool included with Windows 2000 Server, Windows 2000 Advanced Server, and Windows 2000
Datacenter Server. This tool is can be used to verify change certain aspects of the Active Directory. The following is
the steps needed to to view the Flexiible Single Master Operation (FSMO) roles on a given Domain Controller.
Ntdsutil.exe is the only tool that shows you all the FSMO role owners. You can view the PDC emulator, RID
master, and infrastructure master role owners in Active Directory Users and Computers. You can view the schema
master role owner in the Active Directory Schema snap-in. You can view the domain naming master role owner in
Active Directory Domains and Trusts.
1. Click Start, click Run, type cmd in the Open box, and then press Enter.
2. Type ntdsutil, and then press Enter.
3. Type domain management, and then press Enter.
4. Type connections, and then press Enter.
5. Type connect to server <server_name>, where <server_name> is the name of the Win2K domain
controller you want to view, and then press Enter.
6. Type quit, and then press Enter.
7. Type select operation target, and then press Enter.
8. Type list roles for connected server, and then press Enter.
Usi ng t he Wi ndows 2000 Resource Ki t s Dumpfsmos.cmd
The Win2K Resource contains a batch file named Dumpfsmos.cmd that you can use to quickly list FSMO role
owners for your current domain and forest. The .cmd file uses Ntdsutil.exe to enumerate the role owners.
Dumpfsmos.cmd takes a single argument, the name of the domain controller to which it should connect when
querying for FSMO locations. The usage of the command is:
Dumpfsmos <server_name>
Usi ng DCDIAG
Another method involves use of the DCDIAG command. On a Windows 2000 Domain Controller, run the
following command: dcdiag /test:knowsofroleholders /v . Note that the use the /v switch here is required. This
operation lists the owners of all FSMO roles in the enterprise known by that domain controller.
Usi ng AD Repl i cat i on Moni t or
A final method to accomplish this is to use the Active Directory Replication Monitor (Replmon.exe) utility. Before
you can use AD Replication Monitor, youll need to install it. The AD Replication Monitor utility is part of the
Windows 2000 Support Tools, which are located on the Windows 2000 Server CD-ROM in the \Support\Tools
folder. Run the Setup.exe file in this folder to install the tools. Once installed, you can start the AD Replication
Monitor utility by choosing Start\Programs\Support Tools\Tools, and selecting Active Directory Replication
Monitor. Once the utility is running, follow these steps to determine the operations master role holders for the
forest and domain:
1. Right-click Monitored Servers, and then add one or more servers using the wizard.
2. Right-click the servers, and then click Properties.
3. Click the FSMO Roles tab.
4. The domain controllers that hold the operations master roles are displayed under the "Owner" column.
5. To test the connectivity to each of the operations master role holders, click Query to the right of each role.
Usi ng Thi rd-Par t y Ut i l i t i es
Certain third-party utilities, such as NetPros DirectoryAnalyzer (http://www.netpro.com) and NetIQs ADCheck
utility (http://www.netiq.com/ADcheck/Download.asp), provide features to determine the domain controllers
acting as FSMO role holders servers.
An example of viewing the schema master using DirectoryAnalyzer is shown in Figure 5.13.
Figure 5.13: Using a third-par ty utility to determine which domain controller in your forest holds a par ticular FSMO role.
Sei zi ng an Operat i ons Mast er Rol e
If a domain controller holding one or more operations master roles is down during a critical time, will be unavailable
for a long time, or is permanently out of service, youll need to take steps to force the transfer of the role(s) to
another domain controller. You can accomplish feat by using NTDSUTIL. Forcing this type of operations master
role transfer is also referred to as seizing the role on a domain controller. However, before you decide whether to
seize the role of a operations master, be aware that doing so is a major step that should be taken only if the affected
domain controller will never be brought back online. Forcing a transfer in this case should be a permanent action.
Once youve determined where the current operations master role holders in a domain or forest are (using the
information in the previous section), you can use the NTDSUTIL program to transfer the operations master role
from one domain controller in the forest or domain to another in the same forest or domain. To seize an operations
master role on a selected domain controller, follow these steps:
1. On the target domain controller (the domain controller that will be taking over the forest- or domain-wide
operation master role), choose Start>Run. In the Open dialog box, type NTDSUTIL, then click OK.
2. If youre not running NTDSUTIL on the target domain controller, you need to select and connect to it.
At the ntdsutil: prompt, type connections, then press Enter. Type connect to server <server_name>,
where <server_name> is the name of the server you want to use, then press Enter. To supply additional
credentials, type set creds <domain_name user_name_password> and press Enter. At the Server
Connections prompt, type quit, then press Enter again.
3. At the ntdsutil: prompt, enter the word roles.
4. To seize the role on the currently connected domain controller, enter seize <role_type>, where
<role_type> is one of the following: schema master, domain naming master, rid master, infrastructure
master, or pdc. (For a list of roles that you can seize, enter ? at the FSMO Maintenance prompt or see
the list of roles at the beginning of this section.)
5. After you seize the roles, type quit, then press Enter, to return to the previous menu in the NTDSUTIL
interface. Repeat this step until youve exited the utility.
6. Reboot the domain controller that seized the operations master role to complete the role change operation.
If t he current operat ions mast er role holder domain cont roller is online and accessible, or can be
repaired and brought back online, it s recommended t hat you t ransfer t he role using NTDSUTIL s
t ransfer command rat her t han t he seize command. For more informat ion on seizing and t ransferring
flexible single mast er operat ion roles, see Microsoft Product Suppor t Ser vices ar t icles Q255504 and
Q223787, at ht t p:/ / suppor t .microsoft .com.
Checki ng for Inconsi st enci es among Domai n-Wi de Operat i ons Mast ers
Another way to troubleshoot problems on operations masters is to check for inconsistencies among the domain
controllers in a domain. If the domain controllers dont report operations masters consistently, long-term problems,
such as replication problems, can arise. There are a number of third-party utilities on the market capable of detecting
domain controller inconsistencies. One example of such a utility is NetPros DirectoryAnalyzer, which is capable of
inspecting exactly what each domain controller believes are the domain-wide master role assignments. If all domain
controllers fail to report the same values for all the operations masters, there is a problem, and this will be reported.
Figure 5.14 shows an example of using a third-party utility (NetPros DirectoryAnalyzer) to check for operations
master role holder inconsistencies. As the figure shows, the domain controller COMP-DC-04 lists COMP-DC-01
as the owner of the PDC operations master, while domain controller COMP-DC-O3 is the actual owner. Thus,
the owner of the PDC operations master is inconsistent across the domain controllers.
Figure 5.14: Checking for consist ency of t he operat ions mast ers on domain cont rollers.
Troubl eshoot i ng t he Repl i cat i on Topol ogy
When you troubleshoot replication problems and errors, its important to know who the replication partners of a
specific domain controller are and the status of replication with each one.
Vi ewi ng t he Repl i cat i on Par t ners for a Domai n Cont rol l er
You can view the replication partners for a specific domain controller using two tools, DirectoryAnalyzer and
REPADMIN.
When you use DirectoryAnalyzer to see replication partners, youre viewing the replication topology for the selected
domain controller in a forest, and you can check replication consistency among replication partners. In addition,
DirectoryAnalyzer constantly checks the replication topology to ensure that its transitively closed. If it isnt,
DirectoryAnalyzer generates an alert.
Figure 5.15 shows the Replication Information tab in the Browse Directory By Site view. This tab allows you to
view the replication topology and the last successful replication cycle for each replication partner. It also shows the
replication partners and any errors that occurred during replication.
Figure 5.15: Using Direct or yAnalyzer t o view t he replicat ion par t ners for each domain cont roller.
Usi ng REPADMIN
You can also use the Replication Administration utility (REPADMIN) to monitor the current links to other replication
partners for a specific domain controller, including the domain controllers that are replicating to and from the
selected domain controller. Viewing these links shows you the replication topology as it exists for the current domain
controller. By viewing the replication topology, you can check replication consistency among replication partners,
monitor replication status, and display replication metadata.
To use REPADMIN to view the replication partners for a domain controller, enter the command:
REPADMIN /SHOWREPS
Forci ng Domai n Cont rol l ers t o Cont act Repl i cat i on Par t ners
If you detect errors when viewing the replication partners using either the DirectoryAnalyzer utility or the REPADMIN
tool, you can manually force the domain controller to contact its replication partners and authenticate with them.
This is necessary to create the replication links. You can use the following command to force contact:
REPADMIN /KCC
During normal operation, the Knowledge Consistency Checker (KCC) generates automatic replication topology
for each direct or y par t it ion on t he domain cont rollers. You don t need t o manually manage t he replicat ion
t opology for normal operat ion.
In addit ion t o t racking replicat ed changes, many t hird-par t y ut ilit ies also const ant ly evaluat e replicat ion
lat ency across all domain cont rollers. If t he lat ency exceeds t he specified t hreshold, t he
ut ilit y will generat e an administ rat ive aler t and/ or generat e a log ent r y repor t ing t he condit ion.
Tracki ng Repl i cat ed Changes
After the replication links have been re-created, future replication processes should occur automatically at the normal
scheduled time. You can check whether replication is occurring normally among replication partners by tracking a
particular replicated change. This allows you to ensure that the target domain controller is receiving the change. To
perform this check, enter the following for a specific object in AD:
REPADMIN /SHOWMETA CN=CJOHNSON,OU=ENGINEERING,DC=COMPANY,DC=COM
<domain_controller>
In this command, <domain_controller> is the host name of the target domain controller for which youre tracking
replicated changes for CJOHNSON in the ENGINEERING OU in the COMPANY.COM domain. The output
from this command shows the Update Sequence Number (USN), originating DSA, date and time, version number,
and replicated attribute.
Forci ng Repl i cat i on among Repl i cat i on Par t ners
There are several methods that you can use to initiate replication among direct replication partners in a common
name context. For each of the following methods, the source domain controller describes the domain controller
that replicates changes to a replication partner. The destination domain controller receives the changes.
To force replication among replication partners, you can use REPADMIN to issue a command to synchronize the
source domain controller with the destination domain controller by using the object GUID of the source domain
controller. To accomplish the task of forcing replication, you need to find the GUID of the source server. Enter the
following command to determine the GUID of the source domain controller:
REPADMIN /SHOWREPS <destination_server_name>
You can find the GUID for the source domain controller under the Inbound Neighbors section of the output.
First, find the directory partition that needs synchronization and locate the source server with which the destination is
to be synchronized. Then note the GUID value of the source domain controller. Once you know the GUID, you
can initiate or force replication by entering the following command:
REPADMIN /SYNC <directory_partition_DN> <destination_server_name>
<source_server_objectGUID>
An example of running this command to initiate replication between DC1 and DC2 of the domain partition called
COMPANY.COM is seen below. The replication is forced from the source domain controller, DC1, to the destination
domain controller, DC2. To perform the replication, use the following command:
REPADMIN /SYNC DC=COMPANY,DC=COM DC1 d2e3ffdd-b98c-11d2-712c-
0000f87a546b
If the command is successful, the REPADMIN utility displays the following message:
REPLICASYNC() FROM SOURCE: d2e3badd-e07a-11d2-b573-0000f87a546b,
TO DEST: DC1 IS SUCCESSFUL.
Optionally, you can use the following switches at the command prompt:
/FORCE: Overrides the normal replication schedule
/ASYNC: Starts the replication event without waiting for the normal replication to finish.
Youll typically force replication only when you know that the destination domain controller has been down or
offline for a long time. It also makes sense to force replication to a destination domain controller if network con-
nections havent been working for a while.
Vi ewi ng Low-Level AD Repl i cat i on St at us
You can troubleshoot the replication topology another way by viewing the low-level status of AD replication. The
Replication Monitor (REPLMON) utility allows you to do this. Because this tool is graphically based, you can view
the replication topology in graphical form and monitor the status and performance of replication among domain
controllers.
REPLMON provides a view only from the domain controller perspective. Like REPADMIN, you can install it
from the \Support\Tools folder on the Windows 2000 CD-ROM. REPLMON has two options that youll find
helpful when monitoring AD:
Generat e St at us Repor t
Generates a status report for the domain controller. The report includes a list of directory partitions for
the server, the status of the replication partners for each directory partition, and the status of any Group
Policy objects. It also includes the status of the domain controllers that hold the operations master roles, a
snapshot of performance counters, and the Registry configuration of the server.
Show Repl i cat i on Topol ogi es
Displays a graphical view of the replication topology. This option can also display the properties of the
domain controller and any intra-site or inter-site connections that exist for the domain controllers.
Checki ng for KCC Repl i cat i on Errors
Another method of troubleshooting replication problems is to check the entries that might appear in the Directory
Service log in Event Viewer. Event Viewer lists errors that pertain to replication, such as Knowledge Consistency
Checker (KCC) errors. For example, you might see the entry (ID 1311 from event source NTDS KCC) in the
Directory Service log; it means that the Directory Service consistency checker has determined that for changes to
propagate across all sites, replication cannot be performed with one or more critical domain controllers.
When t he KCC generat es t his error message, it s in a mode where it doesn t remove any connect ions.
Normally, t he KCC cleans up old connect ions from previous configurat ions or redundant connect ions.
Thus, you might find t hat t here are ext ra connect ions during t his t ime. The solut ion is t o correct t he
t opology problem so t hat t he spanning t ree can form.
This error could also indicate that there isnt enough physical connectivity to create a spanning tree connecting all
of the sites. A spanning tree is a network algorithm that most network switches use to build tables of media-access-
control-address and port-number associations. This behavior can occur if the KCC has determined that a site has
been orphaned from the replication topology.
One domain controller in a specific site owns the role of creating inbound replication connection objects among
bridgehead servers from other sites. This domain controller is known as the Inter-Site Topology Generator. While
analyzing the site link and site link bridge structure to determine the most cost-effective route to synchronize a
naming context between two points, it might determine that a site doesnt have membership in any site link and
therefore has no means of creating a replication object to a bridgehead server in that site.
The first site in AD (named Default-First-Site-Name) is created automatically. It a member of the default site link
(DEFAULTIPSITELINK) that is also created automatically and used for RPC communication over TCP/IP among
sites. If you create two additional sitesfor instance, Site1 and Site2you need to define a site link that each site
is going to be a member of before these sites can be written to AD. However, you can also edit the properties of a
site link and modify which sites reside in it. If you remove a site from all site links, the KCC displays the error
message listed above to indicate that a correction needs to be made to the configuration.
Troubl eshoot i ng Usi ng Change Management
No discussion of troubleshooting AD would be complete without mentioning one of the most important techniques
available to the network administrator: change management. In any hardware- or software-troubleshooting endeavor,
one of the most important questions an administrator can ask is: What changed to cause this problem? As youve
probably learned from your own experience, most problems dont occur in a vacuum. Rather, they develop as a
result of some change that is made or that occurs in the system. Thus, the ability to know what was changed on
the networkand whenis an invaluable troubleshooting tool.
Obtaining this type of change-management data for AD has been difficult or impossible. Win2K doesnt record
such changes automatically in its event logs, and logging AD infrastructure changes manually is cumbersome and
prone to error. Even third-party AD-management tools have been challenged in this area: Although a number of
tools are available to diagnose problems with and monitor real-time events related to AD infrastructure components,
the ability to analyze the progression of changes to these components over time has remained elusive.
This situation changed recently when NetPro Computing released a new tool, DirectoryInsight. DirectoryInsight is
unique in that it gives administrators a wide array of information about changes to an AD network that occur over
time. This information includes:
Records of all AD infrastructure and configuration changes across the enterprise
A historical record of AD changes, including modifications to such key infrastructure elements as directory
structure, replication, security, and schema
An enterprise-level view of changes to the AD object population that occur over time
Object population counts for GPOs, groups, OUs, domains, domain controllers, servers and computers,
sites, and users at any time.
Figure 5.16: Net Pro s Direct or yInsight AD change-management t ool.
It s a good idea to use change-management information proactively in addition to using it reactively. For
example, you might use t he object -populat ion informat ion t o analyze and plan net work capacit y and t o
predict fut ure t rends and infrast ruct ure needs. This informat ion is invaluable for management repor t s
and Informat ion Technology (IT) budget planning.
With this kind of information in hand, it becomes much easier to investigate the origin of a problem and resolve
it as well as to keep yourself generally "in the loop" about important changes that are being made to your AD
infrastructure. You can view at a glance events such as additions or deletions to AD elements like domains, OUs,
domain controllers, groups and Group Policy, and the AD schema, and you can view the changes to the population
of these elements over time (or at a particular time).
For example, when users at a particular site report suddenly slow network logins that began that morning, you
might analyze your change log and determine that the only domain controller serving the domain on that site was
removed by a site administrator the previous evening. DirectoryInsight consolidates all of the collected data into a
single, centralized database and provides convenient access to it using a Web-based administration tool (an ActiveX
control running in an Internet Explorer browser window.)
A sample DirectoryInsight screen is shown in Figure 5.16.
Summary
Troubleshooting AD means identifying and analyzing problems that occur and repairing them in the various systems.
The troubleshooting process is mostly about isolating and identifying a problem. To troubleshoot AD, you first
check to see whether the domain controllers in the forest can communicate with each other. Next, you need to
ensure that AD has access to DNS and that DNS is working properly. After you verify that DNS is working, you
need to check that the individual domain controllers and operations masters are working properly and supporting
the directory functions. Last, you need to verify that replication is working and that no consistent errors are being
generated.
Chapt er 6
Chapt er 6: Backi ng Up and Recoveri ng Wi ndows 2000 and Act i ve Di rect ory
As a systems administrator, you must protect your network against data loss, computer failures, and loss of directo-
ry services. To accomplish this task, you must back up and restore each Windows 2000 (Win2K) server and the
services each computer provides. You also need to back up and recover critical system data such as the Active
Directory (AD) database, the Registry, and other service-specific configuration databases and configuration files.
Microsoft refers to this set of critical data as System State data.
Its an unfortunate truth that, regardless of what precautions you take or what quality of hardware youve pur-
chased, the odds are that someday, somewhere, youll experience a system failure. If your organization depends on
its Win2K systems, you need to know how to troubleshoot and repair them when they fail. Although Microsoft
has greatly improved system reliability and recoverability in Win2K, things still can and do go wrong. Fortunately,
Microsoft provides tools to help you maintain and recover your system.
In this chapter, Ill cover these new recovery and troubleshooting tools, including the Safe mode startup options,
Win2K Setups Emergency Repair Process, and the Recovery Console. Ill also discuss some advanced recovery
tricks and techniques that you can use to assist in maintaining a high level of OS and network availability. Ill also
mention some third-party tools that complement Win2Ks built-in recovery features.
Bui l di ng a Faul t -Tol erant Syst em t hat Incl udes a Backup and Rest ore St rat egy
The first level of defense against system disaster is ensuring that youve implemented at least minimal levels of fault
tolerance on your network servers. Fault tolerance is generally defined as the resilience of a particular computer,
subsystem, or component to various kinds of failures.
At the network level, implementing system fault tolerance might involve installing power-backup equipment (such
as an Uninterruptible Power Supply, or UPS, with line conditioning) on critical network devices and creating a
fault-tolerant routing topology using dynamic routing protocols. In the case of network servers, implementing sys-
tem fault tolerance usually involves creating backup or redundant resources for critical subsystems. The array of
fault-tolerant features for any important network system should always include, at least, the following:
Di sk redundancyUsing one or more levels of Redundant Array of Independent Disks (RAID)
technology, in which the disk subsystem can withstand the failure of any one drive. You can implement
RAID either using software, such as Win2Ks built-in RAID features (either RAID 1/disk mirroring or
RAID 5/disk striping with parity), or using a hardware RAID device or disk controller).
Power redundancyIn the form of a UPS or power-conditioned backup generator capable of keeping the
system up and running if the power fails. Backup power devices should ideally be connected to the server(s)
they protect using hardware and software (for example, serial or network cabling and either Win2Ks UPS
software or the UPS vendors software). This software can inform the server, network administrator, and/or
network users about various power events that affect system availability. The software can also automatically
initiate a proper system shutdown after a specified amount of time or when batteries are running low.
UPS moni t ori ng and management For example, Win2K includes a UPS monitoring and management util
ity written by American Power Conversion (a leading UPS vendor). In addition, most UPS devices also
include their own customized UPS management software.
Cl ust eri ng sol ut i onsGroup servers into single logical entities. Windows 2000 Advanced Server and
Windows 2000 Datacenter Server include a clustering service as well as a Transmission Control
Protocol/Internet Protocol (TCP/IP) load-balancing component called the Network Load Balancing
service. In addition, there are many third-party Win2K server-clustering solutions available on the mar
ket.
Regul ar syst em backupsMaintain offline data redundancy for all critical system data. For example,
you should develop and thoroughly test for each of your production servers and domain controllers a
backup and recovery plan that includes the operating system (OS) and directory services.
Here are some goals and objectives for developing an effective backup and recovery strategy. You should adapt
and expand these strategies to your environment and situation.
Develop backup and restore methods that ensure that you can quickly recover lost data.
Make sure that you have a backup for each volume that contains the data. In case of total failure, this
strategy allows you to restore the entire volume.
Create a backup of AD that includes the entire domain on the domain controller. The backup should
include user accounts and security information.
Use the log created during backup to determine which files were opened by other applications during
the backup. The names of any files that arent backed up appear in the log, so you can use the log to
keep track of which files arent being backed up and why. In addition, arrange a time to perform a sepa
rate backup of these files during times when the application isnt running.
Keep at least three copies of the backup media and rotate them. In addition, keep at least one copy off
site in case of a catastrophic failure.
Perform a trial restore periodically to verify that your files are being properly backed up. A trial restore
can uncover problems that dont show up using backup verifications.
Secure both the storage device and the backup media to prevent an administrator for another server
from restoring stolen data onto your server. Ideally, this should include keeping an offsite copy as well
as on-site copies of backups.
By far the most important step you can take to prepare yourself for a critical disaster is to back up the system
regularly. Every network should have in place a backup process that regularly copies the system data to secondary
or offline storage devices.
The process should back up the user data files and applications that would need to be recovered if they were lost
or damaged as a result of a disk failing or data becoming corrupted. Backups should also include critical system
data such as the AD database, the Registry, and other service-specific configuration databases and configuration
files.
The acronym RAID originally st ood for Redundant Array of Inexpensive rat her t han Independent Disks
because t he idea was t o use a great er number of cheaper disks rat her t han a Single Large Expensive Disk
(SLED). However, t he definit ion was changed because many modern RAID syst ems are built st rict ly for
redundancy rat her t han cost savings, and t hey oft en use disks t hat aren t necessarily inexpensive.
Wherever possible, choose a hardware-based RAID solut ion over Win2K s soft ware-based RAID. Most hard-
ware RAID solut ions of fer bet t er per formance (many RAID cont rollers include on-board cache random
access memor y (RAM) and dedicat ed processors), advanced RAID levels t hat of fer improved flexibilit y and
per formance, bet t er management feat ures, and easier recover y if a primar y disk in a mirror set (RAID-1
volume) fails.
When you develop your backup strategy, you need to know how long it takes to back up an active server or domain
controller on the network. To assist with this strategy, remember not to back up the server during peak hours.
Instead, schedule backups during off-peak hours so that the impact of the backup process is minimal.
Another important consideration in any backup routine is the timing of backups in relation to the availability of
the data files being backed up. For example, many backup utilities cant back up files that are being used (by users
or applications), so its important to schedule backups to occur during off-hours, when network usage is at its low-
est and the maximum number of files are available to be backed up.
Backing up data during off-peak hours is also important from a performance standpoint. For example, backing up
a computers data taxes the computers resources and makes it less accessible. Also, performing a backup from a
remote computer over the systems primary network connection can significantly reduce network performance.
Usi ng t he Wi ndows 2000 Backup and Rest ore Ut i l i t y
Win2K includes a graphical user interface (GUI)-based backup and restore utility called Backup. (The file is called
Ntbackup.exe.) You can use this utility to back up an entire Win2K system, including AD and other critical data.
The Win2K backup utility has been integrated to copy the core Windows 2000 Server distributed services, which
include AD, File Replication service (FRS), and Certificate Services. Backup lets you back up and restore these
services by checking the System State check box in the utility. Backup also supports Remote Storage, Removable
Storage, disk-to-disk operations, and other new Win2K services and features. You can back up data to a tape drive,
a logical drive, a removable disk, or an entire library of disks or tapes organized into a media pool and controlled by
a robotic changer.
The backup utility lets you perform the following tasks:
Back up selected user files and folders located on the domain controllers hard drive
Back up the domain controllers System State, which are the files central to system operation (the Registry,
AD and SYSVOL, the COM+ Class Registration database, and boot files)
Restore backed-up files and folders to your servers hard drive
Schedule regular backups
Create an Emergency Repair Disk (ERD), which helps you repair system files that become corrupted.
Backup and restore operations can only be performed by backup operators and local administrators. Members of
the Backup Operators group can back up and restore data on the domain controller. (This group is one of the
built-in groups provided by Win2K.) Any domain user can be granted the user rights to back up and restore files
and directories. Members of the Local Administrators group can back up and restore data files, directories, and the
System State of the domain controller.
To start the backup utility, choose Start>Programs>Accessories>System Tools>Backup. Figure 6.1 shows the
Welcome page.
To reduce t he risk of losing dat a, and t o improve dat a securit y, st ore backup set s in a safe t hat is bot h
heat proof and fireproof. In addit ion, as par t of your backup cycle, regularly rot at e one or more full backup
set s t o an of fsit e locat ion. Thus, if all of t he equipment at t he primar y sit e is dest royed, you can st ill
recover your dat a.
The Welcome page provides three main options to assist you in backing up and restoring your data.
Backup Wi zardHelps you back up your programs and files to help prevent data loss and damage caused
by disk failures, power outages, virus infections, and other potentially damaging events.
Rest ore Wi zardHelps you restore your previously backed-up data in the event of a hardware failure, acci
dental erasure, or other data loss or damage.
Emergency Repai r Di skHelps you create an ERD that you can use to repair and restart Win2K if its
damaged. This option doesnt back up your files or programs, and its not a replacement for regularly back
ing up your system.
In addition to these options, the tabs on the Welcome page allow you to bypass the wizards and select backup and
restore options manually.
Usi ng t he Backup Wi zard
To perform a basic backup of your domain controller, click Backup Wizard and follow the on-screen instructions.
Speci fyi ng Defaul t Opt i ons
When you run the Backup Wizard and accept the default settings, all of your computers data files and System
Figure 6.1: The Welcome page of t he Win2K backup ut ilit y.
You can also st ar t t he backup ut ilit y from a command-line int er face or prompt . At t he command prompt on
t he local comput er, simply t ype Nt backup.
State data are backed up as a set. The Backup Wizard lets you back up the data to a file or tape on the target com-
puter. When you back up the data, you have to designate a file name and location. Backup files typically have the
.bkf extension, but you can use any extension to override the default. You can save a backup file to a hard drive,
floppy disk, or removable or non-removable media.
Figure 6.2 shows the What to Back Up dialog box, where you select what you want to back up.
In the next dialog box, you can select the type of backup media and the location and name of the destination back-
up file. (By default, the file is called Backup.bkf.)
You can use the backup utility to back up and restore data on either file allocation table (FAT) or NT file system
(NTFS) volumes on your system or domain controller. If you back up data from an NTFS 5 (Win2K NTFS) vol-
ume, you should in most cases restore it to an NTFS 5 volume. If you restore the data to a FAT or Windows NT
4.0 or earlier NTFS volume, youll lose certain file and folder features, and youll lose data as wellfor example,
file permissions, Encrypting File System (EFS) settings, disk quota information, mounted drive information, and
remote storage information.
The Completing the Backup Wizard dialog box, shown in Figure 6.3, presents a summary of your current selec-
tions and allows you to specify additional options, if needed. (These are discussed in "Specifying Advanced
Options" below.) Clicking Finish starts the backup, and the Backup Progress dialog box tracks the progress of the
backup. (See Figure 6.4.)
Figure 6.2: The Backup Wizard prompt s you t o select what you want t o back up on t he local
comput er.
Figure 6.3: The Complet ing t he Backup Wizard dialog box displays a summar y of your current
select ions and allows you t o choose addit ional backup opt ions.
Figure 6.4: The Backup Progress dialog box t racks t he progress
of t he backup.
Speci fyi ng Advanced Opt i ons
Instead of clicking Finish in the Completing the Backup Wizard dialog box, you can click Advanced and customize
the backup. The Type of Backup dialog box appears, where you can select the specific type of backup to perform.
(See Figure 6.5.)
The backup utility allows you to perform the following types of backup:
Normal Copies all selected files and marks each one as having been backed up. (This clears the archive
attribute.) Performing a normal backup of all files restores the state of your computer to the time of the
backup using only the one normal backup. If you then create incremental or differential backups, you have
to restore all the incremental backups or the latest differential after restoring the normal backup.
A normal backup creates a backup of the files, folders, and drives selected with the entire System State of
the server or domain controller while its online. (See "Maintaining System State Backups" later in this
chapter.) If the server is a domain controller, AD is backed up as part of the System State. When you back
up the System State for the local computer, you cannot choose to back up individual components of the
System State data because of dependencies among them.
CopyAllows copies of all selected files but doesnt mark each one as having been backed up. (This means
that the archive attribute is cleared.) If you want to back up files between normal and incremental backups,
copying is useful because it doesnt affect these other backup operations.
Increment al Allows you to back up only those files that have been created or changed since the last nor
mal or incremental backup. It marks files as having been backed up. If you use a combination of normal
and incremental backups, restoring files and folders requires that you have the last normal backup set as
well as all subsequent incremental backup sets.
Figure 6.5: The Type of Backup dialog box allows you t o choose t he mode, or t ype, of backup t o
per form and whet her t o back up t he dat a files t hat have been migrat ed t o Remot e St orage.
Di f ferent i al Allows you to back up files created or changed since the last normal or incremental backup.
It doesnt mark files as having been backed up. (This means that the archive attribute isnt cleared.) If youre
performing a combination of normal and differential backups, restoring files and folders requires that you
have the last normal as well as the last differential backup.
Dai l yAllows you to copy all selected files that have been modified on the day the daily backup is per
formed. The backup files arent marked as having been backed up.
You can also perform a combination of backups. For example, backing up your domain controller data using nor-
mal and incremental backups requires the least amount of storage space and is the quickest backup method.
However, recovering files can be time-consuming and difficult because the backup sets can be stored in several dif-
ferent places, disks, and/or tapes. On the other hand, backing up your domain controllers data using a combina-
tion of normal and differential backups is more time-consuming, especially if your data changes frequently, but its
easier to restore the data because the backup set is typically stored on only a few disks or tapes.
After youve selected the type of backup and whether to back up data files migrated to Remote Storage, you can use
the How to Back Up dialog box (shown in Figure 6.6) to specify whether you want the backup to be verified.
Verification reads the backed-up data to ensure its integrity. Verification takes extra time but helps ensure that the
backup is successful.
You can also specify whether you want the backup to use hardware compression, if available. Hardware compres-
sion allows the backup to try and reduce the size of the data files and System State being backed up. Backup files
that have been backed up using hardware compression must be restored to hard drives that support compression.
Figure 6.6: The How t o Back Up dialog box provides opt ions t o verify t he backup and suppor t
hardware compression, if available on t he local ser ver.
Another dialog box (not shown) allows you to specify whether to append the backed-up data to an existing backup
file or to replace the existing backup file with the new backup data. The next dialog box, the Backup Label dialog
box, allows you to customize the backup and media labels that are stored with the backup file. (See Figure 6.7.) To
make your life easier, the labels include the date and time of the backup.
In the next dialog box, you can decide when to perform the backup. You can choose Now to perform it immediate-
ly or Later to schedule a time (preferably during off-peak hours) to have the backup run. (Scheduled backups are
discussed in "Backing Up Using Manual Selection" below. After youve selected all the advanced options, the
Completing the Backup dialog box appears again and summarizes your backup configuration. Click Finish to run
the backup. When it completes, a backup status report is displayed, as shown in Figure 6.8.
Figure 6.7: The Backup Label dialog box allows you t o cust omize t he backup and media labels.
Figure 6.8: The backup st at us repor t shows t he det ails of t he finished backup.
Backi ng Up Usi ng Manual Sel ect i on
As I mentioned earlier, instead of using the Backup Wizard, you can manually select the options you want to be
available during backup. To do this, on the Welcome page of the backup utility, click the Backup tab. In the
Backup dialog box (shown in Figure 6.9), you can select the data files, folders, and drives to be backed up. You can
also select the storage media, file location, and name for the backup data.
Figure 6.9: The Backup dialog box allows you t o select t he dat a files, folders, and drives t hat you want t o be backed
up as well as t he backup file name, locat ion, and media t ype.
Here you can perform the following tasks and set up the backup configuration:
Sel ect t he dat a fi l es, fol ders, and dri ves t o be backed upThe Backup dialog box provides a tree view of
the local files and folders that you can back up. You can use this tree view the same way you use Windows
Explorer to open devices and select files and folders.
Sel ect st orage medi a and backup dest i nat i onBackups provide two options for selecting storage media:
removable and non-removable storage devices and tape devices. Storage devices can be hard drives, floppy
disks, and Zip and Jaz drives. The tape device option is only available when the local computer has a tape
drive installed.
After youve made your selections, click Start Backup. The Backup Job Information dialog box appears (shown in
Figure 6.10). Here you can customize the backup by specifying a name and a label for the backup and whether the
data should be appended to the backup media.
When youve selected these options, click Start Backup to start the backup. The backup utility displays the Backup
Progress dialog box (see Figure 6.4), where you can track the backup procedure.
One handy new feat ure in t he Win2K backup ut ilit y is it s abilit y t o back up t o alt ernat ive backup media
such as hard disks, Jaz and Zip drives, opt ical drives, compact disc-recordable/ rewrit able (CD-R/ RW)
drives, and digit al video disc-ROM (DVD-ROM) drives. As a rule, if it has a logical drive let t er and Win2K
can writ e files t o it , Win2K Backup can use it as a dest inat ion backup device.
If you want to schedule the backup to run at a later time (and unattended), click Schedule; the backup utility will
wait and run the backup at the scheduled date and time you specify. To specify additional backup options, click
Advanced to select the backup type, whether to verify the backup, and whether to back up remote media. You can
specify the type of backup (Normal, Copy, Incremental, Differential, or Daily), indicate whether you want a log file
to record the actions, exclude certain file types from the backup, and verify whether the backup was successful. (For
information on the types of backup, see "Specifying Additional Options" above.)
Mai nt ai ni ng Syst em St at e Backups
Win2K allows you to back up and restore system components known as System State data or System State backups.
The contents of a System State backup depend on the type of Win2K computer and include:
The Registry
System boot files (including all system files)
AD service
COM+ Class Registration database
Certificate Services database
SYSVOL folder
Cluster service information
Here is a breakdown of System State backup components by OS:
Wi ndows 2000 Professi onal A copy of the system Registry hive files (as with an ERD), the COM+ Class
Registration database, the system boot files, including Ntldr, Ntdetect.com, and other system data, such as
performance-counter configuration files and all files protected by Windows File Protection (WFP).
Wi ndows 2000 ServerThe Registry, COM+ Class Registration database, system boot files, and, if the
server is a certificate server, Certificate Services information.
Wi n2K server t hat i s al so a domai n cont rol l erIn addition to the components for Windows 2000 Server,
a copy of the AD database (Ntds.dit), the log and checkpoint files, and the contents of the SYSVOL folder.
Wi n2K server t hat i s al so runni ng Domai n Name Syst em (DNS)In addition to the components for
Windows 2000 Server, Directory Services (DS)-integrated as well as non-DS-integrated DNS zone informa
tion.
Wi ndows 2000 Advanced Server act i ng as cl ust er membersIn addition to the components for Windows
2000 Server, a copy of the quorum recovery log file.
Figure 6.10: The Backup Job Informat ion dialog box allows you t o cust omize
t he backup job you ve creat ed.
To back up System State data, run the Win2K backup utility and click the Backup tab. In the tree list at the left,
click the System State check box. You have the option of selecting only System State data for a backup or including
it as part of a larger backup that includes local disk volumes. Finally, note that the files migrated to near-line stor-
age by Win2K Remote Storage (RS) and those protected by WFP are only included during a backup if you select
Back Up Data That Is in Remote Storage and Automatically Back Up System Protected Files with the System State,
respectively.
When you back up the System State, a copy of the Registry is placed on the local system partition in a folder under
%Systemroot%\Repair\Regback (such as C:\Winnt\Repair\Regback). If the system Registry files are deleted or
damaged, you can use these backup copies of the Registry hive files to repair your system (for example, using the
Recovery Console) without performing a full restore of the System State data using the Win2K backup utility.
To restore the System State on a domain controller, you must first start your computer in Directory Services
Restore mode. This allows you to restore AD and the SYSVOL folder. When you back up or restore the System
State data, you get all the System State data that is relevant to your server or domain controller. You cannot back
up or restore individual components of the data because of dependencies among the components of the System
State. However, you can restore the System State data to an alternate location; if you do, only the Registry files,
SYSVOL folder files, cluster service information, and system boot files are restored.
Usi ng t he Rest ore Wi zard
If you want to restore the data files and System State data that youve backed up, you can choose Restore Wizard on
the backup utilitys Welcome page. If a hard disk fails, the Restore Wizard allows you to recover the entire system to
an operational system or restore the system from the ground up.
Before using the Restore Wizard, however, I recommend that you collect the information in Table 6.1; youll need
it to perform a successful restore.
For Thi s Do Thi s
Disk configuration Using the Disk Management system utility, record the volumes and sizes of the disks
in your system. If a disk should completely fail, youll use this information to re-cre-
ate the disk configuration. All disk configurations must be restored before restoring
the System State or data to your computer. If you dont, the restore process may fail
or the computer may not start after the restore has finished.
Server name Record the server name. Youll use it to restore a computer of the same name and
avoid changing many different client configuration settings.
Internet Protocol (IP)
addresses
If the computer has a static IP address, record it so you can set it up manually if you
need to. However, in most cases, the IP address should be restored with the Registry.
Domain information
Know what domain this computer belongs to and be prepared to set up a new com-
puter account for it. Even if the computer name doesnt change, you may need to re-
establish a new account.
Local administrative
password
You must know the local computers administrative password used when the backup
was created. If you dont know it, you cant log on to the computer once its restored
to establish a domain account for the computer. If youre not part of the domain,
you cant use a domain account; this applies even if youre domain administrator.
Moreover, the local administrators password is also required to restore the System
State on a domain controller.
Table 6.1: Informat ion required t o per form a successful rest ore.
Figure 6.11: The Welcome page for the Restore Wizard.
When you click Next on the Welcome page, the What to Restore dialog box appears, where you can select the spe-
cific data set that you previously backed up (shown in Figure 6.12). The Restore Wizard provides you with a tree
view of the files and folders the data was in when it was backed up. You can navigate the tree to select the files and
folders in the same way that you use Windows Explorer. The label that you selected for the backup identifies the
data set.
Figure 6.11 shows t he Welcome page for t he Rest ore Wizard.
I don t recommend using t he rest ore procedure for copying a syst em from one comput er t o anot her. The
backup of t he Syst em St at e is ser ver-specific.
When you click Next, the Completing the Restore Wizard dialog box appears. Like its equivalent in the Backup
Wizard, this dialog box shows your current selections and allows you to select advanced options, if needed. You
start the restore by clicking Finish. As in the Backup Wizard, a progress dialog box appears, where you can track
the restore.
Speci fyi ng Advanced Opt i ons
Instead of running the restore, you can click Advanced on the Completing the Restore Wizard to specify advanced
options. In this case, the Where to Restore screen appears, which lets you select one of three destinations for your
restored files. (See Figure 6.13.)
Figure 6.12: The What t o Rest ore dialog box provides a t ree view of t he dat a set s t hat have
been creat ed. You navigat e t he t ree t o select t he files and folders t hat you want t o rest ore.
You can restore to:
Ori gi nal l ocat i onThe folder(s) the data was in when it was backed up. This option is useful if youre
restoring files and folders that have been damaged or lost.
Al t ernat e l ocat i onRetains the structure of the backed-up folders and files. This option is useful if you
know youll need some old files, but you dont want to overwrite or change any of the current files or fold
ers on your disk.
Si ngl e fol derDoesnt retain the structure of the backed-up folders and files. Only the backed-up files are
placed here. This option is useful if youre searching for a file and you dont know its location.
After you select the location for the restored files, the How to Restore dialog box appears, where you select
how you want your files and folders restored. Again, you have three options.
Don t repl ace t he fi l e on my comput erPrevents files from being overwritten on your hard disk. This is the
safest method of restoring files.
Repl ace t he fi l e on t he di sk onl y i f t he fi l e i s ol derAllows you to make changes to the files since you last
backed up your data. This option ensures that you dont lose the changes youve made to the files.
Al ways repl ace t he fi l e on my di skReplaces all of the files on your hard drive with files in your backup
data set. If youve made any changes to the files since you last backed up, your data will be replaced with
the backed-up data.
Once youve made your selection, the Advanced Restore Options dialog box allows you to specify whether you
want to restore security, the Removable Storage database, and/or junction point data. (See Figure 6.14.)
Figure 6.13: The Where t o Rest ore dialog box allows you t o select t he locat ion of rest ored
files and folders.
The last dialog box in the Restore Wizard provides a summary of the selections that youve made and lets you start
the restore process. Like the Backup Wizard, once you start the restore process, a progress dialog box appears,
which provides details during the restore and completion information once its done.
Rest ori ng Requi red Servi ces
If you have to perform a restore, several server services require special attention to make them operational. Table
6.2 lists the services that require additional effort. The sections below the table provide additional information
about restoring each service.
Figure 6.14: The Advanced Rest ore Opt ions dialog box allows you t o rest ore securit y and/ or
special syst em files.
When you rest ore t he Syst em St at e, your recover y plan should t ake int o account t he fact t hat t he age of
t he backup t ape must n t exceed t he AD t ombst one lifet ime (t he lengt h of t ime t hat delet ed object s are
maint ained in AD before t he syst em permanent ly removes t hem). The default for t his value is 60 days. If a
t ape older t han t he t ombst one is rest ored, t he rest ore applicat ion programming int er faces (APIs) will reject
all of t he dat a as being out of dat e. Microsoft discusses t his issue in Product Suppor t Ser vices ar t icle
Q216993, " Backup of t he Act ive Direct or y Has 60-Day Useful Life." This underscores t he impor t ance of
per forming regular backups of AD.
Thi s Servi ce Requi res Thi s
Wi ndows Int ernet Nami ng Servi ce (WINS)
On a TCP/IP network, the Windows Internet Naming Service (WINS) dynamically maps IP addresses to comput-
er names (Net BIOS names). Because of this, WINS lets users access resources by name instead of requiring them
to use IP addresses that are difficult to recognize and remember. WINS servers support clients running NT 4.0 and
earlier versions of Microsoft OSs.
WINS The WINS database is restored to the state it was in at the time of the back-
up. This overrides the current state of the server.
DHCP DHCP leases are restored to their state at the time of the backup. You must
perform several steps to reconcile the state of this database with the current
state of the network.
Remote Storage During a restore operation, the Remote Storage database is recalled from tape
media when you restart the servicebut only if the tapes are available.
Certificate Services server After a restore operation, this server may have outstanding certificates that are
now unknown. You can revoke and re-issue these certificates or leave the old
certificates orphaned.
Windows Media
Services server
After a restore operation, you may have to re-install this server because the
database containing setup information may be lost.
Internet Information
Services (IIS) server
If you perform a complete restore, no problems with IIS should arise. If you
perform a partial restore, you must follow the backup/restore procedures spe-
cific to the IIS service.
AD In a network with more than one domain controller, the default restore
method (non-authoritative) is generally the preferred method for restoring a
failed server. Use the authoritative restore process outlined later in this chapter
(see "Authoritative Restores") only if you want to get the system back to the
state at the time the backup was made. (Youd want to do this, for example, if
you erroneously deleted AD objects from the database and it would be diffi-
cult to re-create them. For more information, see "Developing a Backup and
Restore Strategy for Active Directory" later in this chapter.)
SYSVOL If the computer being restored is the only domain controller on the network,
you must select a restore option in the Advanced Restore Options dialog box
in the backup utility. Otherwise, you need to use the default (non-authorita-
tive) restore process.
Table 6.2: How t o handle required ser ver ser vices when per forming a rest ore.
When a Win2K server receives a request from a client computer asking for a mapping from a friendly name to an
IP address, WINS responds. When a restore is completed, the WINS database is restored, but it may be out of date
because the information on the network is dynamic. The database updates itself over time and within a day or two
should be consistent. During this time, some name requests may go unanswered or contain incorrect mappings. If
the WINS database is replicated among several WINS servers (the recommended procedure), you should initiate
replication, which synchronizes the database with the up-to-date server. If no other server is available, its best to let
the database synchronize on its own.
Dynami c Host Confi gurat i on Prot ocol (DHCP)
Dynamic Host Configuration Protocol (DHCP) is a networking protocol that offers dynamic configuration of IP
addresses for computers. DHCP ensures that address conflicts dont occur and helps conserve the use of IP address-
es by centrally managing address allocation.
The DHCP server allocates IP addresses and other network-configuration information to DHCP-aware network
clients. Using DHCP is the most common way to distribute IP addresses in a modern network. The restore process
restores the DHCP database. However, its restored to the date the backup was performed, and this can result in
duplicate IP addresses being issued. Having duplicate addresses causes those computers to cease all network opera-
tions.
To avoid this, DHCP has a Safe mode of operation. In Safe mode, DHCP broadcasts on the network to verify that
the IP address its about to issue isnt already in use. After a restore, you need to reconcile the database and enter
Safe mode for a period of one-half of the IP lease duration. Because Safe mode significantly reduces network and
server performance, and because being in Safe mode for this period of time is enough to ensure that DHCP func-
tions properly, Microsoft recommends quitting Safe mode as soon as the one-half lease duration is met.
To reconcile the DHCP database, run the DHCP snap-in, then choose Action>Reconcile while the scope is high-
lighted. In the scope properties dialog box, choose Conflict Detection under Advanced and set the number of
attempts to 1.
Remot e St orage Servi ce
The Remote Storage service (the Win2K version of Hierarchical Storage Management) frees up disk space by mov-
ing data from the local hard disk to a remote storage device (such as a tape), from which it can be recalled whenev-
er needed. Users still see and access the data without knowing that its been archived.
The Remote Storage service cannot recall its database from the Remote Storage tape during the restore operation
unless the Remote Storage tape is in the correct drivethat is, the drive configured to be the Remote Storage
deviceor in the robotic library. If any issues with the service exist, the tape will restore by using the database copy
that the service stores on the tape. This is an automatic process that requires no user intervention.
Cer t i fi cat e Server
Certificate Server is the Win2K service that issues X.509 security certificates for a particular Certificate Authority
(CA). It provides customizable services for issuing and managing certificates for the enterprise.
After performing a restore operation, you dont have to take any special steps for Certificate Server. However, cer-
tificates may exist on the network that were issued before the restore operation. Although Certificate Server is now
unaware of these certificates, theyre valid and will continue to function.
Int ernet Informat i on Server (IIS)
Internet Information Server (IIS) is a set of software services that supports Web-site creation, configuration, and
management, along with other Internet functions. If you perform a complete system restore, you dont need to take
additional steps to restore IIS. If you perform a partial restore of a file only, you may need to use the IIS Microsoft
Management Console (MMC) snap-in to restore the IIS database. Youll find instructions on doing this in the IIS
Help pages.
Act i ve Di rect ory
For a detailed discussion of how to back up and restore AD as a service, see "Developing a Backup and Restore
Strategy for Active Directory" later in this chapter.
SYSVOL
SYSVOL is a replicated data set that contains the policies and scripts that are used by some Windows security sys-
tems. SYSVOL uses Win2Ks FRS for distribution throughout the network. The three restore options for SYSVOL
are identical to the options for FRS: non-authoritative (the default), authoritative, and primary.
Creat i ng an Emergency Repai r Di sk (ERD)
You can also use the backup utility to create an Emergency Repair Disk (ERD), which contains critical information
about your Win2K systems settings. An ERD can be a very helpful resource when you attempt to fix an unstartable
server because it contains information that can help Win2K Setups Repair mode repair problems with your
Registry, system files (if theyre accidentally erased or become corrupt), your startup environment, and/or the parti-
tion boot sector on your boot volume.
To create an ERD, make sure you have a blank 1.44-megabyte (MB) floppy disk. Then on the Welcome page of
the backup utility, click Emergency Repair Disk to start the ERD Wizard. From there, you have a single option
whether you also want to update the hard diskbased copy of the Registry files (which are stored in the
%Systemroot%\Repair folder). By default, this folder contains versions of the Registry hive files that were created
right after the Win2K setup process was completed. Therefore, if you want to preserve the original set of Registry
files created during Setup but still update the files when the ERD is created, you need to first copy the files in this
folder to another location.
An ERD contains three files:
Aut oexec.nt A copy of the %Systemroot%\System32\Autoexec.nt file, which initializes the MS-DOS
Virtual DOS Machine (VDM) environment used to run MS-DOS and 16-bit Windows applications.
Confi g.nt A copy of the %Systemroot%\System32\Config.nt file, which initializes the MS-DOS VDM
environment used to run MS-DOS and 16-bit Windows applications.
Set up.l ogA log of files installed during Win2K Setup, along with checksum information that can be
used during the Setup Repair process (an option of Win2K Setup) to verify files against their original
source copies on the Win2K installation source (for example, the Windows 2000 CD-ROM). The
Setup.log file has read-only, system, and hidden attribute flags set, so it isnt normally visible unless you
configure Windows Explorer to show all files.
You need t o rest ore SYSVOL and AD t oget her; however, t o clarify t he issues involved, t his chapt er
explains t hem separat ely. For a det ailed discussion of how t o back up and rest ore AD as a ser vice, see
" Developing a Backup and Rest ore St rat egy for Act ive Direct or y" lat er in t his chapt er.
Opt i ons t o Use When Your Server or Domai n Cont rol l er Won t St ar t
In addition to the internal reliability enhancements (such as WFP, driver signing, and the driver verifier) that make
Win2K less prone to crashes than Windows NT, Microsoft has introduced three new system-recovery features that
make repairing an unstartable Win2K system easier. These are described briefly below and in more detail in the fol-
lowing sections. Third-party tools are another option.
Safe mode boot i ngThe first option to try is Safe mode and related startup options. This option is easy
and understandable to use. A related option is Last Known Good Configuration, which may provide a solu
tion in situations where a recently installed driver or service is causing problems.
Recovery Consol eIf Safe mode fails, the next option to try is the Recovery Console. Only advanced or
administrative users should use this option. This method of starting a failed system uses the OS Setup CD-
ROM or ERD floppy disks you created from the Setup CD-ROM.
Wi ndows 2000 Set up Emergency Repai r Process If the Safe mode and Recovery Console options dont
work, try rerunning the Setup program from the Windows 2000 CD-ROM. It may (but isnt guaranteed
to) repair the system and make it startable.
Thi rd-par t y recovery t ool sThere are a number of excellent third-party recovery tools on the market that
you can use to assist you in troubleshooting and recovering unstartable Win2K systems.
Safe Mode
Safe mode is a boot option that lets you disable certain OS features so that you can successfully start the system.
For example, you can remove offending configurations, such as a newly installed driver, which might be causing a
problem.
Safe mode has a number of startup options that allow you to start using varying system configurations. For exam-
ple, the regular Safe mode starts Win2K in a bare-bones environment (set of drivers and services). It doesnt provide
access to high-resolution video drivers, nor does it provide networking or other optional services.
To access most of these choices, you press F8 on the Windows 2000 Boot Loader menu when you start up. This
selection displays a menu of the following alternative safe-start options:
Safe ModeStarts Win2K with the minimal set of drivers and services necessary. These basic files and
drivers support the mouse, keyboard, monitor, mass storage, and other common services.
Safe Mode wi t h Net worki ngSimilar to Safe mode but adds drivers and services necessary to enable net
working.
Safe Mode wi t h Command Prompt Similar to Safe mode but starts Win2K with a Command Prompt
window instead of Windows Explorer.
Enabl e VGA ModeStarts Win2K in VGA mode by using the Vga.sys driver instead of the regular video
driver.
When you creat e an ERD, informat ion about your current syst em set t ings is saved in t he
%Syst emroot %\ Repair folder. Don t delet e or change t his folder, or you may not be able t o repair problems
wit h your syst em. There is a bug in t he ERD creat ion ut ilit y t hat prevent s t he hard diskbased copies of
t he Regist r y files and t he ERD floppy disk from being creat ed if t he %Syst emroot %\ Repair folder is empt y
when you st ar t creat ing an ERD. Therefore, if t his folder is empt y (t hat is, you moved or delet ed t he files),
you may need t o rest ore t hem t emporarily from copies made on eit her t hat syst em or anot her syst em t o
creat e t he ERD. Also, don t t r y t o creat e an ERD when your syst em is already having problems; t he ERD
cannot fix fut ure problems.
Last Known Good Confi gurat i onStarts Win2K using a previous version of the system Registry hive. The
Last Known Good Configuration is the most recent session in which a user successfully started up without
any service or driver-initialization failures and logged on to the computer.
Di rect ory Servi ce Rest ore ModeRecovers the AD database. This option is extremely helpful when you
recover AD and is valid only for Win2K domain controllers. If you plan to start a domain controller in Safe
mode and then use the backup utility with removable storage or AD, this is the only option that supports
this. Note that when you start up a domain controller in Safe mode, AD runs, and you need to log in with
domain credentialsfor example, as the domain Administrator. When you start up in Directory Service
Restore mode, AD isnt started, and you log in with local machine credentials.
Debug ModeEnables a startup mode in which the system sends debugging information across a serial
cable to another computer running a debugger. (The mode uses COM2 as the debugging port.)
Enabl e Boot Loggi ngCreates an extended log file of success events and failure events to initialize system
components as they load when Win2K starts. (This behavior is the default for all Safe mode boot options
except for the Last Known Good Configuration and Directory Service Restore mode.) The log file is named
ntbtlog.txt and resides in the %Systemroot% folder (for example, C:\Winnt).
Depending on the type of problem youre experiencing with a system, one or more of these options might be
appropriate in a given set of circumstances.
The Recovery Consol e
If Safe mode doesnt start your system, try using the Recovery Console. The Recovery Console is a special boot
mode that provides a command-line interface. You can use it to start and stop services, read and write data on a
local drive (including drives formatted with NTFS), copy data to and from a floppy disk or CD-ROM, format
drives, fix the boot sector or master boot record, and perform other administrative tasksall outside the Win2K
environment.
The Recovery Console is particularly useful if you need to repair your system by copying a file from a floppy disk
or CD-ROM to your hard drive, or if you need to reconfigure a service that is preventing your computer from
starting properly. For example, you can use the Recovery Console to replace an overwritten or corrupted driver file
with a good copy from a floppy disk.
Usi ng t he Recovery Consol e
To use the Recovery Console:
1. Insert the Windows 2000 Setup CD-ROM into the CD-ROM drive.
2. When the text-based part of the Setup begins, follow the prompts. Choose the REPAIR option
by typing R.
3. When youre prompted, choose the Recovery Console by typing C.
4. If you have a system that has more than one OS installed, choose the Win2K installation that you need
to access.
5. When youre prompted, type the administrator password.
6. At the system prompt, type Recovery Console commands, then type either Help for a list of commands
or Help <command name> for help on a specific command.
7. Quit the Recovery Console and restart the computer by typing Exit.
The Recover y Console is ext remely power ful, so I recommend it only for advanced users and administ rat ors.
Addi ng t he Recovery Consol e t o t he St ar t up Opt i ons
If you want to be able to start Win2K using the Recovery Console, you can add it as an option to the Boot Loader
menu on a functioning computer. To do this:
1. With Win2K running, insert the Windows 2000 CD-ROM into the CD-ROM drive.
2. Choose File>Run.
3. In the Open dialog box, type: D:\I386\Winnt32 /Cmdcons (where D: is the drive letter assigned to your
CD-ROM drive)
4. Follow the on-screen instructions to complete the installation.
The commands for the Recovery Console allow you to accomplish simple operations such as change to a different
directory or view a directory, and more powerful operations such as fixing the boot sector on the hard drive. You
can display help for the commands by simply typing Help at the Recovery Console command prompt.
Wi ndows 2000 Set up Emergency Repai r Process
Another system-recovery option is using the Win2K Setup emergency repair process (or Repair) option. This mode
of Setup, like its Windows NT predecessor, allows you to perform some basic system-repair operations.
Assuming you have an ERD for the non-booting system (for more information on this, see "Creating an
Emergency Repair Disk" earlier in this chapter), make sure you have it ready during this procedure. (Even if you
dont have an ERD, it may still be possible to use Setup Repair mode to recover the system; see the sidebar below,
"Using Windows 2000 Setup Repair without an ERD.")
The following steps provide a general overview of how to use the emergency repair process from the Setup CD-
ROM:
1. St ar t your comput er from t he Wi ndows 2000 Set up di sks or CD-ROMYou can only start your computer
from the CD-ROM if your computer hardware and basic input/output system (BIOS) have been set up to
support this option.
2. Choose t he repai r opt i on duri ng set upAfter your computer starts up, the Setup program starts, and
youre asked whether you want to continue installing the Win2K OS. Press Enter to continue. The installa
tion process starts and allows you to repair your system. During installation, you can choose whether to
install a fresh version of Windows 2000 Server or repair an existing installation of Win2K. To repair a dam
aged or corrupt system, type R. Youre then asked whether you want to repair your system using the
Recovery Console or the emergency repair process. Type R to use the emergency repair process.
3. Choose t he t ype of repai rYou can choose either the Fast Repair option (type F) or the Manual Repair
option (type M). The Manual Repair option requires that you make all the repair selections and determine
whether you want to repair system files, the partition boot sector, or startup environment problems. I rec
ommend that only advanced users and administrators use the Manual Repair option and that you use it
only to repair one item at a time when you know the others are intact. For example, if youre confident that
the partition boot sector and startup environment are both intact, attempt to repair only the system boot
files. (The Manual Repair option doesnt let you try to repair problems with the Registry. To manually
repair individual Registry settings and files or replace the entire Registry, use the Recovery Console.
However, administrators should be the only ones who use it.)
For a more ext ensive discussion of t he capabilit ies, commands, and use of t he Recover y Console, check
out Chapt er 12 of t he free eBook The Definit ive Guide t o Windows 2000 Administ rat ion by Sean Daily and
Darren Mar-Elia. You ll find a link t o it at www.realt imepublishers.com.
The Fast Repair option uses a backup copy of the Registry that was created when Setup was first run or
installed on your system. If you choose this option, you may lose settings or preferences youve created since
the system was first installed unless youve created a System State backup. In this case, the system is restored
to that state.
4. St ar t t he repai r processIf you have the required ERD (on a 1.44-MB floppy disk), which you created
using the backup utility, and the original Windows 2000 Server CD-ROM, you can start the repair process.
If you dont have an ERD, the emergency repair process can attempt to locate your Win2K installation and
start repairing as best it can, but it may not be able to fix everything. If you dont have the ERD and the
emergency repair process cant fix your system, you can try to use the Recovery Console or try to re-install
Win2K.
5. Rest ar t your comput erIf the emergency repair process was successful, your computer should automati
cally restart, and the repair procedure is complete.
Devel opi ng a Backup and Rest ore St rat egy f or Act i ve Di rect ory
As the heart and soul of a Win2K network, AD is an essential component that must be available to applications
and users at all times. Because its a replicated database, AD is vulnerable to the same kinds of problems that can
plague any database. These problems include, but arent limited to:
A corrupted or invalid database schema (which defines the structure of the databasewhat type of data it
contains and how the data is arranged)
Missing DNS records
Damaged or corrupted information
Accidental misconfiguration by an administrator.
In case one of these events occurs, its imperative that your disaster-preparation routine and disaster-recovery plan
include provisions for backing up and restoring AD.
Usi ng Wi ndows 2000 Set up Repai r wi t hout an ERD
If you haven t prepared an ERD, you can at t empt t o repair a downed ser ver by rerunning t he Set up program
from t he Windows 2000 Ser ver CD-ROM. Assuming t hat it can locat e t he Win2K inst allat ion folder (improving
t he abilit y t o locat e t he Win2K inst allat ion is one of t he primar y benefit s of having an ERD), Set up might be
able t o repair t he syst em using informat ion saved at t he t ime t hat you originally ran it t o inst all t he ser ver. This
informat ion is saved in t he %Syst emroot %\ Repair folder on t he syst em par t it ion. If t his informat ion is physically
accessible and int act , Set up can use it during t he repair process. However, some syst em set t ings may be lost
under t hese circumst ances; for more informat ion about t his, refer t o t he Win2K document at ion.
Wint ernals Soft ware Recover y Tools
If you need more help t han even Windows 2000 s Set up Repair mode and t he Recover y Console can
of fer, you may find a savior in t he t ools available from Wint ernals Soft ware. Wint ernals makes a number
of t op-not ch t ools (including ERD Commander 2000, Disk Commander, NTRecover, and NTFSDOS)
designed t o help you recover Windows NT and 2000 syst ems, including even t hose t hat are t ot ally
unst ar t able because of corrupt ion or misconfigurat ion. Wint ernals even makes one t ool (Remot e Recover)
t hat makes it possible t o per form over-t he-net work recoveries on comput ers t hat you aren t physically
present wit h. You can find a list ing and descript ion of t hese t ools at www.wint ernals.com.
Backi ng Up Act i ve Di rect ory
Because the files that make up AD (including Ntds.dit, the primary database file) are continually in use on Win2K
domain controllers, you cant simply copy the AD database as you might a standard user data file. However, as dis-
cussed earlier in this chapter (see "Maintaining System State Backups"), the Win2K backup utility provides a fea-
ture for performing an online backup of AD. AD is backed up whenever you include System State data as part of a
backup on a Win2K domain controller.
When you back up System State data on a domain controller, youre backing up all AD data that exists on the serv-
er (along with other system components such as the SYSVOL folder and the Registry). You cannot choose to back
up or restore individual components of the System State data or of AD; its an all-or-nothing process. This is
because of the dependencies among the components of the System State.
Although the Win2K backup utility can certainly do the job of backing up AD, most information technology (IT)
shops prefer to use more robust third-party applications for their backup solutions. If your organization is using a
third-party backup application, you need to make sure that youve purchased a Win2K-compatible version of the
product. It must be capable of backing up AD or provide a separate agent component that can do so. Windows
NT 4.0era versions of backup utilities are incapable of understanding ADs format or backing it up, so for most
companies, migrating to Win2K necessarily means upgrading their backup software.
Rest ori ng Act i ve Di rect ory
Although the process of physically restoring the AD database on a Win2K domain controller from a backup isnt
logistically complex, there are some important logical and architectural issues you need to take into consideration
before performing any type of AD restore operation. On networks with more than one Win2K domain controller,
remember that AD is automatically replicated and updated among domain controllers and thus doesnt exist in only
a single location. This has implications for restoring AD. For example, you need to ask questions such as:
Third-Par t y Windows 2000 Backup Ut ilit ies
There are several excellent t hird-par t y Win2K backup ut ilit ies t hat are 100% compat ible wit h backing up
and rest oring AD. The leaders in t he Win2K backup arena include:
- Backup Exec from Verit as (www.verit as.com)
- ARCser veIT from Comput er Associat es (www.cai.com)
- Ult raBAC for Windows NT/ 2000 from Ult raBac Soft ware (www.ult rabac.com)
- ERDisk for Act ive Direct or y from Aelit a Soft ware (www.aelit a.com)
You can back up AD in it s ent iret y only using a full backup; you can t back up AD increment ally (t hat is, by
backing up only object dat a t hat has changed since t he last backup)..
As discussed in " Specifying Advanced Opt ions" earlier in t his chapt er, t he useful life of a backup of AD is
usually only 60 days, so you may experience problems if you at t empt t o rest ore AD backup images older
t han t his int o a replicat ed Win2K net work. The reason for t he 60-day figure is t hat t he useful life of a back-
up is ident ical t o t he t ombst one lifet ime set t ing for t he ent erprise, and in Win2K, t he default value for t he
t ombst one lifet ime ent r y is 60 days. However, you can change t his value using t he Direct or y Ser vice (NTDS)
config object . The value is t he " t ombst oneLifet ime" at t ribut e of t he CN=Direct or y Ser vice, CN=Windows NT,
CN=Ser vices, CN=Configurat ion, DC=COMPANY, DC=COM (for a domain called " company.com" ). You can set
t he value using t he LDP or ADSI Edit ut ilit y..
Is just the local domain controllers copy of AD corrupted or damaged, or are other replicas on other
domain controllers also in the same state?
Is the data being restored the definitive copy that should be used to overwrite all other copies of AD object
data? If so, are there changes or structural modifications that might be lost by restoring this copy of AD as
a "master" copy?
Do you need to restore AD on a local domain controller only to regain functionality on that domain con
troller (for example, is the problem isolated to the local copy of AD on that computer), and should it then
receive updates from other domain controllers using AD replication to bring its data store up to date?
The answers to these questions will help you determine which of the three AD restore modes to choose: non-
authoritative, authoritative, or primary.
Non-Aut hori t at i ve Rest oreA normal restore; most restore operations are run using this restore mode. You
usually perform a non-authoritative restore when the problem is limited to the local Win2K domain con
troller and the AD replicas housed on other Win2K domain controllers are believed to contain valid repli
cas. During a non-authoritative restore, any data that you restore (including AD objects) retains its original
update sequence number (USN). (AD uses the USN to detect and propagate any changes to the other
domain controllers.) In turn, AD replication uses the USN to detect and propagate any changes to the
other domain controllers in the same domain.
Aut hori t at i ve Rest oreUsed when the other Win2K domain controllers contain invalid replicas or unde
sirable data. In this case, you manually designate the copy of the AD database that you restore. You desig
nate only the local domain controller to be authoritative (that is, the "master" copy from which all other
domain controllers seed their own AD replicas). An authoritative restore modifies the USN of each AD
object that is being restored to the domain controller. This allows the USN of each object to be higher than
any of those that are currently on the domain controller. After all of the objects have been restored, theyre
replicated to the other replicas.
You can use backup dat a from one domain cont roller t o rest ore only t o t he same domain cont roller. You
cannot use t he backup of one domain cont roller t o rest ore anot her comput er. However, if t he domain con-
t roller s syst em fails and never comes back, you can rest ore t he backup dat a t o anot her comput er t hat will
t ake t he place of t he original domain cont roller. In addit ion, t o complet ely back up your environment , you
need t o have a backup of ever y domain cont roller on t he net work. Keep t his in mind when developing your
backup st rat egy. Also, because of t he impor t ance t o t he ent ire syst em of t he domain cont roller t hat was
creat ed first in t he root domain, you need t o frequent ly back it up.
If you re using Win2K s backup ut ilit y (Nt backup.exe) t o per form a rest ore, be aware of t he following addi-
t ional condit ions, which must be met for t he Syst em St at e (including AD) t o be successfully rest ored. If any
of t hese condit ions isn t met , t he rest ore will fail.
- The ser ver name must be ident ical t o t he backed-up ser ver name.
- The drive on which t he %Syst emroot % folder is locat ed must be t he same as when it was backed up.
- The %Syst emroot % folder must be t he same folder as when it was backed up.
- If SYSVOL or ot her AD dat abases are locat ed on anot her volume, t he dat abases must exist and be on t he
same drive as when t hey were backed up.
Non-aut hori t at i ve Rest ores
If the AD replicas on domain controllers other than the one youre performing the restore on are intact and valid,
youll probably want to perform a non-authoritative restore. A non-authoritative restore is a normal, or typical,
restore of the AD objects to the domain controller that originally contained them.
You restore AD by starting the Win2K domain controller in Directory Services Restore mode (discussed in "Safe
Mode" earlier in this chapter). When the system starts up, press F8 at the Windows 2000 Boot Loader menu, then
select Directory Services Restore Mode from the alternate boot menu. Win2K starts in a safe mode, and you can
follow these steps to restore AD information on a domain controller:
1. Log on as a member of the Administrators or Backup Operators groups. I should also point out that the
members are local computer users and groups, not domain users and groups. Also, users who are backup
administrators (but not regular administrators) cant run Ntdsutil to do things like authoritative restores.
This requires a user with administrative privileges.
2. Run the Win2K backup program. On the Welcome page, click Restore Wizard, then select the System
State check box.
If you restore the System State data and you dont designate an alternate location for the restored data, the
backup utility erases the System State data that is currently on your computer and replaces it with the
System State data youre restoring. If you restore the System State files to an alternate location, the AD
database, the Certificate Services database, and COM+ Class Registration database arent restored.
3. Once the restore is complete, restart the domain controller.
After the non-authoritative restore is complete, the restored data (which may be out of date) becomes synchro-
nized. Once you restart the domain controller, it should begin participating in AD replication and receive directory
updates from the other domain controllers.
You can use a non-authoritative restore if the domain controller fails or the entire AD database is corrupt because
you can simply restore the entire system data non-authoritatively. In more technical terms, this means that a non-
authoritative restore retains the original USN.
A non-authoritative restore provides a start point (the time at which the data was backed up) for data replication.
This minimizes the replication traffic on the network because only changed data is replicated rather than the entire
directory. In the absence of this start point, all data would be replicated from other servers.
While it s possible t o back up AD eit her online (while t he direct or y ser vices are running) or of fline (when
t he ser vices are st opped), you can rest ore AD only when t he direct or y ser vices are of fline.
Anot her opt ion for rest oring a Win2K domain cont roller is t o simply re-inst all Win2K and reconfigure t he
syst em as a domain cont roller on it s domain. You can give t he domain cont roller a dif ferent name, or if
you rebuild it wit h t he same name, you need t o first remove t he old domain cont roller from t he domain.
Aft er you ve done t his, t he normal AD replicat ion process repopulat es t he domain cont roller wit h current
direct or y informat ion.
Aut hori t at i ve Rest ores
An authoritative restore allows you to recover a domain controller, restore it to a specific time, and mark objects in
AD as being authoritative with respect to their replication partners. For example, if an administrator inadvertently
deletes an organizational unit (OU) containing a large number of users, you can perform an authoritative restore to
recover the information and mark it as the source to force replication to the other domain controllers.
By definition, an authoritative restore replicates any changes made to the current data set to its outbound replica-
tion partners. To be the authoritative source for the restore, the authoritative restore modifies the USN of the AD
objects that are being restored to the domain controller so that each object has a higher value than any of those that
are currently on the domain controller. This forces the restored objects to be replicated to the other replicas of the
same domain controller.
Such a restore is unusual, but it has the effect of rolling back all of the AD objects in the domain controller to the
time of the original backup. You can do this to restore erroneously deleted information of a replicated set of data.
For example, if you inadvertently delete or modify objects stored in AD, you may want to authoritatively restore
them so that they can be replicated again to the other domain controllers. If you dont authoritatively restore these
objects, theyre never replicated to the other domain controllers in the same domain because they appear to be older
than the objects currently on your domain controller.
To help you accomplish an authoritative restore, you can use the Ntdsutil utility to mark the target objects for
authoritative restore. This ensures that the data you want to be restored is replicated to the appropriate domain
controllers after the restore occurs. Table 6.3 describes the commands in Ntdsutil available to perform an authorita-
tive restore.
Thi s Command Does Thi s
Authoritative restore
(main menu option)
Allows you to use the authoritative restore submenu options listed below. You
can use this option only on a domain controller that is operating in Directory
Services Restore mode.
Restore database
(submenu option)
Marks the entire AD database (Ntds.dit) as authoritative.
Restore database verinc %d
(submenu option)
Marks the entire AD database (Ntds.dit) as authoritative and increments the
version number by %d. Use this option only to authoritatively restore over a
previous sequential authoritative restore.
Restore subtree %s
(submenu option)
Marks a subtree (all objects in the subtree) as being authoritative. The subtree
is defined by using the distinguished name (DN) of the OU object.
Restore subtree %s verinc %d
(submenu option)
Marks a subtree (all objects in the subtree) as being authoritative and incre-
ments the version number by %d. The subtree is defined by using the DN of
the OU object. Use this option only to authoritatively restore from a backup
that contains the objects you want to restore over.
Table 6.3: The Nt dsut il aut horit at ive rest ore commands.
To perform an authoritative restore of AD on a specific domain controller:
1. Choose Start>Run or open a Command Prompt session.
2. Type Ntdsutil, then press Enter.
3. At the NTDSUTIL prompt, type Authoritative Restore, then press Enter. (This puts Ntdsutil into
Authoritative Restore mode.)
4. At the Authoritative Restore prompt, to set the entire database as authoritative, type Restore Database.
OR
To set only a subtree of the database as authoritative (for example, an individual OU), use the
Lightweight Directory Access Protocol (LDAP) DN that identifies the portion of AD being authorita
tively restored. For example, to authoritatively restore the Engineering OU in the
REALTIMEPUBLISHERS.COM domain, type the following:
RESTORE SUBTREE "OU=ENGINEERING,DC=REALTIMEPUBLISHERS,DC=COM"
5. When youre prompted to confirm the authoritative restore, answer YES.
6. Type Quit, then press Enter twice to return to the command prompt.
7. Close the Command Prompt session.
Once AD is restored, be certain to answer No to the option to restart the server. This step is critical because the
restore will otherwise be non-authoritative when the server restarts, and youll risk re-inheriting unwanted data
from other AD replicas.
Always aut horit at ively rest ore SYSVOL whenever you aut horit at ively rest ore AD and vice-versa. This
ensures t hat SYSVOL and AD st ay synchronized.
There are a few pot ent ially negat ive consequences of aut horit at ive rest ores t hat you should be aware of.
One such ef fect relat es t o t rust relat ionships and comput er account passwords. Bot h of t hese are aut omat -
ically negot iat ed at a specified int er val (ever y seven days, by default , except for comput er account s t hat
can be disabled by t he administ rat or). During an aut horit at ive rest ore, a previously used password for t he
object s in AD t hat maint ain t rust relat ionships and comput er account s can be rest ored. In t he case of t rust
relat ionships, t his could void communicat ion wit h ot her domain cont rollers from ot her domains. Wit h com-
put er account passwords, t his could void communicat ions bet ween t he member workst at ion or ser ver and a
domain cont roller of it s domain. In t his case, you may have t o manually reest ablish t rust s t o resume proper
communicat ions.
Rest ori ng FRS Dat a
I want t o make a point about using Win2K s backup ut ilit y t o rest ore replicat ed FRS dat a set s as par t of rest oring a
domain cont roller. If you want t o mark t he rest ored dat a as t he primar y dat a for all replicas, you need t o set a spe-
cial opt ion t hat ensures t hat rest ored FRS dat a is replicat ed t o your ot her ser vers. Specifically, when you rest ore
Syst em St at e dat a, select t he Advanced opt ion t o access t he Advanced Rest ore Opt ions dialog box, t hen select
When Rest oring Replicat ed Dat a Set s, Mark t he Rest ored Dat a As t he Primar y Dat a for All Replicas. If t his domain
cont roller is a member of FRS replica set s ot her t han t he SYSVOL replica set , t hose ot her replica set s will also be
rest ored as aut horit at ive. If you want t o rest ore only t he SYSVOL replica set , select t he opt ion in t he backup ut ilit y;
t hen, aft er t he rest ore is complet e, delet e t he ot her replica set s.
If you don t select t his opt ion, t he FRS dat a t hat you re rest oring may not be replicat ed t o ot her ser vers because t he
rest ored dat a will appear t o be older t han t he exist ing dat a. The ot her ser vers will over writ e t he rest ored dat a, and
t his will ef fect ively prevent you from rest oring t he FRS dat a. Third-par t y backup applicat ions also provide similar
opt ions for per forming primar y rest ores.
Veri fyi ng Rest ores
Once youve restored AD, you can verify that it was successful. You can do this using either advanced verification or
basic verification. You must perform basic verification; advanced verification is optional, but you must run it before
you run basic verification.
Advanced
Advanced verification is optional; it isnt usually required for normal recovery operations. You run it regardless of
whether you performed an authoritative restore. If you do run it, you must do so before you run basic verification.
Incorrectly using the Ntdsutil utility may corrupt the AD database, and youll have to restore the database from
backup again.
To perform advanced verification:
1. Make sure that youre in Directory Services Restore mode.
2. Choose Start>Run.
3. In the Open dialog box, type Regedit, then click OK.
4. In REGEDIT, select the Registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS and check that it contains a
subkey called Restore In Progress. (This key is automatically generated by the Backup utility during the
restore and indicates to AD that the database files have been restored and need to be checked and re-
indexed the next time AD is started. When this check is completed, this key is automatically removed;
dont manually add or delete it.)
5. Close REGEDIT.
6. To check for the recovered AD database files, start Ntdsutil by typing Ntdsutil at a command prompt or
in the Start>Run dialog box.
7. At the NTDSUTIL prompt, type Files. At the File Maintenance prompt, type Info. (If the AD files have
been recovered successfully, you can see the difference. Dont select any other options.)
8. To exit File Maintenance, type Quit. To exit Ntdsutil, type Quit. To exit the DOS prompt, type Exit.
9. Restart the server in Normal mode. Log on to the system normally and perform basic verification (see
below).
Basi c
Basic verification consists of rebooting and logging on normally, then confirming that the restored services are in a
state consistent with a successful restore. It also includes verifying that FRS and Certificate Services were successful-
ly restored.
To perform basic verification:
1. Restart the computer. (AD will automatically detect that its been recovered from a backup, perform an
integrity check, and re-index its database. Both AD and FRS will be brought up to date from their repli
cation partners using the standard replication protocols for each of those services.)
2. Confirm that distributed services successfully restored. (You should be able to browse AD and confirm
that all of the user and group objects that were present in the directory before the backup were restored.)
3. Confirm that files that were members of an FRS replica set and certificates that were issued by the
Certificate Service are present.
The Act i ve Di rect ory Backup Bug
There was a fairly serious bug in early versions of Win2K. This bug makes Win2K-based domain controllers unable
to start in AD mode after you restore System State backups that were created before installing Windows 2000
Service Pack 2. Restoring these backups to a Win2K domain controller leaves the directory services unable to start,
and the system records a number of errors in the system Event Log. The problem affects all applications that use
the backup APIs to perform AD backups; this includes System State backups performed with Win2Ks built-in
backup utility as well as most third-party backup applications.
Affected backups are corrupted in such a way that when theyre restored, they prevent the domain controller from
starting and cause it to display a "Directory Service cannot start" error message. Also, if you run Ntdsutil using the
Semantic Database Analysis option to run the database semantic checker, you receive error message 550: "Database
is inconsistent." With the backup utility, the problem happens even when the Verify option is turned on.
You can avoid these problems by installing SP2, then making new backups of the System State. The fix is preventa-
tive only; it doesnt resolve errors that occur if you restore System State backups that contain incorrect header infor-
mation.
How It Occurs
As mentioned earlier in this chapter, you prepare for AD disaster recovery by making System State backups from
the console of Win2K-based domain controllers at regular intervals. The elements of AD that are captured in a
System State backup include the AD database (Ntds.dit), transaction logs (Edb*.log), and a patch file (Edb.pat).
You restore by starting Win2K domain controllers in Directory Service Repair mode and restoring the System State
using the Win2K backup utility, Ntbackup.exe, or a third-party equivalent. After performing the restore operation,
you can optionally use Ntdsutil.exe to mark specified domain name paths or subtrees as authoritative when the
domain controller next starts in AD mode.
The following conditions also contribute to this problem:
An initial backup of AD is performed on a Win2K domain controller. During the backup, a number of
objects change as a result of either local changes or replication. The changes to these objects generate addi
tional transaction logs, which in turn advance the Joint Engine Technology (Jet) database checkpoint. The
Jet checkpoint maintains a list of unflushed data in the database. Two copies of the checkpoint data are
stored: One in the database header of the Ntds.dit file and a second in-memory copy, which is written to
the backup media.
A second backup is performed on another, relatively inactive domain controller. During the backup, the
log files arent generated, and the Jet checkpoint isnt advanced. This second backup completes before the
log files are generated and the Jet checkpoint advances in the first backup.
The second backup is then restored.
In order for the problem to manifest itself, the new transaction logs and Jet checkpoint advancement that occur
during the first backup must happen after the second backup completes. As a result, a relatively large first backup is
more likely to produce the problem because there is a commensurately larger window of time for the second back-
up to complete (and for the Jet checkpoint to advance). Domain controllers in busy production environments are
less likely to experience this problem during typical activity (creating, deleting, and modifying objects) because
these activities in AD result in a steady advance of the Jet checkpoint.
The problem is more likely to occur in large backups (or when the backup media doesnt have a fast backup rate)
because the backup process takes longer and there is more opportunity for the checkpoint file to advance. The
essential problem is that a second backup is made before the checkpoint file advances, then the second backup is
restored.
The result of all this, and the core of the problem, is that an outdated record of required transaction log files and
checkpoint data is written to the backup media, then later restored as the second backup. The header in the
restored database references logs that arent actually required for the AD recovery and that arent all included in the
backup. This explains why log entries appear stating, "Log files are missing from System State." However, such
entries are misleading because it isnt a case of the log files being missing; instead, the number of log files referenced
in the restored database header is incorrect.
Worki ng Around It
If you use backups as a method of recovery for Win2K-based domain controllers, you may want to consider doing
the following to work around the bug:
Inventory, then clearly label backups that were made before installing SP2. Place pre-SP2 backup media in
locked storage. Dont forget backup media that are stored on the local drives of computers in your organi
zation.
Consistent with good change-management practices, install SP2 on domain controllers in a lab environ
ment that is representative of your production configuration. Make multiple backups, then initiate restore
tests.
Install SP2 on production domain controllers. Create new System State backups and clearly label them as
post-SP1 backups.
Destroy pre-SP2 backups.
Repai ri ng a Domai n Cont rol l er i n Act i ve Di rect ory
If a Win2K domain controller fails, you have several options for repairing it. You might need to use more than one
or even all of them.
Use the ERD to either prepare a set of disaster-recovery disks, or use a set of previously established disks to
repair specific components of a domain controller so that it can successfully start up. Log on using an
account that has Administrator or Backup Operator privileges.
Re-install the Windows 2000 Server OS and run the Active Directory Installation Wizard. If a major hard
ware failure or malfunction requires the computer to be completely rebuilt, you may need to re-install the
OS. After the computer is running, reconfigure the original network connections and DNS settings.
If you need to remove a domain, run the Active Directory Installation Wizard to remove AD from all
domain controllers that youre removing. Then use the NETDOM utility to remove the domain itself
(including cross-reference and trusted domain objects). To do this, type the following at the command
prompt:
netdom trust /remove /force
To clean up metadata that has been left behind by decommissioned or failed domain controllers, you can
use Ntdsutil with the CLEANUP command. This operation removes the defunct domain controllers
identification and information from AD.
Summary
The guidelines for backing up and restoring Win2K servers and domain controllers include information for
Win2K and AD. You can use the Win2K backup utility to back up and restore data and perform emergency recov-
eries. To back up and restore a failed server to an operational state, you use the backup utilitys Backup and Restore
wizards.Alternatively, you can back up and restore selected user files and folders on the domain controllers hard
drive.
You can back up and restore the domain controllers System Statethe files central to system operation; they
include the Registry, AD and SYSVOL, the COM+ Class Registration database, and boot files. You can also sched-
ule regular backups and create an ERD that helps you repair system files should your system become corrupted.
Without Sean Daily, The Definitive Guide to Active Directory Troubleshooting wouldn't be a definitive guide at all.
Sean has been running Active Directory since early beta, and he knows it inside and out. Check out his beefy bio
below! And, don't miss the backgrounder on the company he writes for. NetPro's ebook is the second comprehensive
guide published by Realtimepublishers.com that's free and available on the web - and it won't be the last!
Sean Daily is a world-renowned expert on Windows NT/2000 and a Senior Contributing Editor at Windows 2000
Magazine. In addition to being the author of numerous books, including The Definitive Guide to Windows 2000
Administration (Realtimepublishers.com) and Optimizing Windows NT (IDG/Hungry Minds), Sean speaks and
consults internationally on Windows NT/2000 and related technologies. Sean also serves as Series Editor for
Realtimepublishers.com's Definitive Guide and Tips and Tricks Guide series of ebooks.
About t he Tech Edi t or
NetPro's own Chief Scientist, Gil Kirkpatrick, performed the technical edits for the ebook. Kirkpatrick is an expert
in the design and development of large-scale distributed software for enterprise networks and has over 24 years of
industry related experience. He is a recognized authority on commercial network directories, including Banyan's
StreetTalk, Novell's NDS eDirectory and Microsoft's Active Directory. In his previous position as NetPro's Director
of Engineering, Kirkpatrick was responsible for the development of NetPro's directory management products and
served as the architect and lead engineer for NetPro's flagship product, DirectoryAnalyzer. Kirkpatrick joined
NetPro in 1994 when NetPro acquired his company, High Technology Systems. Kirkpatrick is also the author of
Active Directory Programming, published by MacMillan USA.
The Defi ni t i ve Gui de t o Act i ve Di rect ory Troubl eshoot i ng About t he Aut hor
About t he Aut hor

NetPro AD DFN Gde Troubleshooting

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

NetPro AD DFN Gde Troubleshooting

Hochgeladen von

Copyright:

Verfügbare Formate

Ask the average Windows system administrator what they think the most prominent feature of Windows 2000 is

Das könnte Ihnen auch gefallen