The Definitive Guide To Active Directory Troubleshooting

Foreword by Peter Houston 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 Windowsbased 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 updateable 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 network configuration problems) some troubleshooting will eventually be required. Then, it will be important to understand how Active Directory's parts fit together in order to get to the root of the issue quickly. I believe that this innovative, on-line book from NetPro and Realtimepublishers.com will prove to be a valuable resource for any administrator who is tasked with managing an Active Directory installation. The approach to information delivery is ideal. The book starts with important background concepts that will enable the reader to understand the design of Active Directory and relationships between components, in a clear and concise way. Later chapters build on this knowledge by providing step-by-step procedures for diagnosing common issues even when the root cause of an issue may not be clear. Most important, this book provides a methodology for proactively keeping an Active Directory installation healthy while simultaneously enabling administrators to get to the root causes of problems quickly when they do occur. Such a methodology can be 'worth its weight in gold' to today's systems administrators who are responsible for keeping ever-more complex systems up and running with ever-less downtime! Peter J. Houston Group Program Manager, Active Directory Microsoft Corporation Redmond, Washington March 6th, 2001

The Definitive Guide to Active Directory Troubleshooting

Foreword

Table of Contents Chapter 1 Introducing Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 The Importance of Directories and Directory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Many Eggs, One Basket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 New Tools for New Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Meet Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 The AD Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Logical Architecture of AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Objects and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Domains, Trees and Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Organizational Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 The Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Physical Structure of AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Directory Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 The Operations Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 AD’s Backbone: DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Introduction to AD and Win2K Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 AD and Win2K Monitoring Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Change Monitoring and Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Problem Resolution, Automation and Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Chapter 2 Designing an Effective Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Active Directory’s Logical and Physical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Logical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Naming Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Physical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Designing Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Designing the Forest and Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Determining the Number of Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Setting Up and Managing Multiple Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Determining the Number of Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Designing the Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Determining the Number of Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Choosing a Forest Root Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

The Definitive Guide to Active Directory Troubleshooting

table of contents

Using a Dedicated Root Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Assigning a DNS Name to Each Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Using an Internet-Registered Name for the Top-Level Domian . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Using Internet Standard Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Using Locations to Name Child Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 Never Using the Same Name Twice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Dividing the Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Placing the Domain Controller for Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Determining Trust Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Using Bi-Directional Transitive Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Using One-Way Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Using Cross-Link Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Designing Organizational Units for Each Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Creating OUs to Delegate Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Creating OUs to Reflect Your Company’s Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 Creating OUs for Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Creating OUs to Restrict Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Designing the Sites for the Forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Creating Sites and Site Links Based on Network Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 About Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 About Site Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Creating the Site Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Using Sites to Determine the Placement of Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Using Sites to Determine the Placement of DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Chapter 3 Monitoring and Tuning the Windows 2000 System and Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Monitoring Windows 2000 Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Monitoring the Overall System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Using Task Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Using the Performance Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Events Tracked in Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Types of Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Starting Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Types of Events Logged by Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Sorting and Filtering Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Exporting Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Monitoring Memory and Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 Using Task Manager to View Memory on a Domain Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Using the Performance Console to Monitor Memory on a Domain Controller . . . . . . . . . . . . . . . . . . . . .65 Available Memory Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Page-Fault Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Paging File Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 System Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

The Definitive Guide to Active Directory Troubleshooting

table of contents

Monitoring Processors and Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 Using Process Viewer to Monitor Processes and Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Using Task Manager to View Processes on a Domain Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Working with the List of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 Viewing Information about Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 Using the Performance Console to View Processes on a Domain Controller . . . . . . . . . . . . . . . . . . . . . . .75 % Processor Time Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Interrupts/sec Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 Processor Queue Length Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Monitoring the Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Using the Performance Console to Monitor the Disk Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 % Disk Time and % Idle Time Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Disk Reads/sec and Disk Writes/sec Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Current Disk Queue Length Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 % Free Space Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Monitoring the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Using Network Monitor to Watch Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82 Using the Performance Console to Monitor Network Components on a Domain Controller . . . . . . . . . . . . .83 Domain Controller Network Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Network Interface Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Chapter 4 Monitoring Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Using the Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Third-Party Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 DirectoryAnalyzer from NetPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 AppManager from NetIQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Built-In Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 System Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 Replication Diagnostics (REPADMIN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 Monitoring the AD Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Monitoring the Domain Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 Using NTDS Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 Monitoring the Domain Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101 Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101 Using Domain Database Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 Installing the Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 Monitoring the Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105 Monitoring Operations Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107 Monitoring Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 Using Directory Partition Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 Schema Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

The Definitive Guide to Active Directory Troubleshooting

table of contents

Configuration Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 Domain Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 Using Directory Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 Using Replication Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

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

The Definitive Guide to Active Directory Troubleshooting

table of contents

Relative ID (RID) Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Infrastructure Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 PDC Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149 Determining the Operations Master Role Holders Locations . . . . . . . . . . . . . . . . . . . . . . . . . .150 Using the DSA and Schema MMC Snap-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150 Using NTDSUTIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 Using the Windows 2000 Resource Kit’s Dumpfsmos.cmd . . . . . . . . . . . . . . . . . . . . . . . .151 Using DCDIAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 Using AD Replication Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 Using Third-Party Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152 Seizing an Operations Master Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152 Checking for Inconsistencies among Domain-Wide Operations Masters . . . . . . . . . . . . . . . . . .153 Troubleshooting the Replication Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Viewing the Replication Partners for a Domain Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Using DirectoryAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154 Using REPADMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 Forcing Domain Controllers to Contact Replication Partners . . . . . . . . . . . . . . . . . . . . . . .155 Tracking Replicated Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 Forcing Replication among Replication Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156 Viewing Low-Level AD Replication Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157 Checking for KCC Replication Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157 Troubleshooting Using Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160

Chapter 6 Backing Up and Recovering Windows 2000 and Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Building a Fault-Tolerant System That Includes a Backup and Restore Strategy . . . . . . . . . . . . . . . . . . . . .161 Using the Windows 2000 Backup and Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Using the Backup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 Specifying Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 Specifying Advanced Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 Backing Up Using Manual Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Maintaining System State Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 Using the Restore Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Specifying Advanced Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Restoring Required Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Windows Internet Naming Service (WINS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . . . . . . . . . . . . . . . . . .179 Remote Storage Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179 Certificate Server Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179 Internet Information Services (IIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 Active Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 SYSVOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 Creating an Emergency Repair Disk (ERD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 Options to Use When Your Server or Domain Controller Won’t Start . . . . . . . . . . . . . . . . . . . . . . . . . . . .181

The Definitive Guide to Active Directory Troubleshooting

table of contents

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

The Definitive Guide to Active Directory Troubleshooting

table of contents

eBook Introduction

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 [email protected], leaving feedback on our website at www.realtimepublishers.com, or calling us at (707)539-5280. Thanks for reading, and enjoy! Sean Daily Series Editor

The Definitive Guide to Active Directory Troubleshooting

Introduction

Chapter 1

The Definitive Guide to Active Directory Troubleshooting

Introducing Active Directory As computer networks have evolved over the years, the focus in enterprise computing has shifted away from a PC network operating system-centric (NOS) model to one based on the concept of directories, or directory services. A directory service is a network service that stores information about network resources and makes those resources available to network users and applications. Directories also provide an environment that allows for the uniform naming, location, access, management, and security of network resources. These days, nearly all companies with large enterprise-level networks, and even many of those with small- to medium-sized networks, employ one or more directories within their organization. Although the concept of directories has been around for some time, it is only in recent years that the directory has moved into the limelight of network computing. Although Microsoft’s Windows NT operating system introduced a pseudo-directory in the form of the NT Directory Service (whose heart and soul was the Security Accounts Manager – SAM – database), this "directory" had a number of major limitations. Among these were: Non-hierarchical structure and namespace

NT’s directory used a flat, non-hierarchical directory structure that didn’t support the naming and structural needs of complex organizations. Lack of extensibility

NT’s directory stored only basic user information and couldn’t be inherently extended. Lack of scalability

The NT directory was stored inside the NT system registry database; due to this architecture, the maximum number of users topped out in the neighborhood of around 40,000 per domain. Poor manageability features

Administration roles weren’t layered and couldn’t be natively delegated. Poor directory replication performance

Because NT’s architecture was bandwidth- and network topology-ignorant, the NT operating system couldn’t automatically tune replication frequency and bandwidth usage to adapt to variable WAN link speeds between multiple physical locations within a network. Single-master, Single point of failure architecture

NT’s architecture called for a single server in each network domain – the Primary Domain Controller (PDC) – to house the "master" copy of the directory, thus making it a single point of failure for logon authentication for the entire domain. In Windows 2000 (Win2K), NT’s successor OS, Microsoft set out to deliver a directory capable of addressing each of these limitations. Win2K’s new directory service, dubbed Active Directory (AD), provides an industrial-strength

Chapter 1

1

www.netpro.com

directory service that can serve the needs of both small and very large organizations, and everyone in between. Because it stores its data outside the system registry, AD has virtually unlimited storage capacity (AD databases can contain hundreds of millions of entries, as compared to the tens of thousands NT is capable of ). AD allows administrators to define physical attributes of their network, such as individual sites and their connecting WAN links, as well as the logical layout of network resources such as computers and users. Using this information, AD is able to self-optimize its bandwidth usage in multi-site WAN environments. AD also introduces a new administration model that provides a far more granular and less monolithic than was present under NT 4.0. Finally, AD also provides a central point of access control for network users, which means users can log in once and gain access to all network resources. Although other directories such as Banyan’s StreetTalk and Novell’s NDS have existed for some time, many Windows NT-centric organizations have opted to wait and use Microsoft’s entry in the enterprise directory arena as the foundation for their organization-wide directory environment. Consequently, Win2K’s Active Directory will represent the first foray into the larger world of directories and directory management for many organizations and network administrators. The Importance of Directories and Directory Management Directories provide a logically centralized repository for all critical information within an enterprise network. Rather than spreading information around between many different databases, organizations can use a centralized directory such as Win2K’s Active Directory to consolidate all critical company information in a single shared network resource. In addition to improving organizational efficiency, this move also allows for significant reductions in the total cost of ownership (TCO) of the corporate network. The concept of wholesale migration to Active Directory has also become more feasible with both existing and announced support from major application vendors, including those producing enterprise resource planning (ERP), groupware, human resources, and accounting packages. Many Eggs, One Basket

Although the large-scale centralization and consolidation of critical data is one of the most significant benefits of migrating to a directory-based network operating system such as Win2K and its Active Directory, this also represents one of its greatest potential weaknesses. Whenever critical information is moved from a distributed model to one that is highly centralized, the tolerance for downtime and problems is greatly reduced, 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 software compatibility, and application interoperability under the Win2K environment. Although these are certainly worthwhile and important considerations, they are by no means the only steps required to guarantee a successful Win2K deployment. In addition to compatibility and capacity issues, IT departments within these organizations must also determine what additional tools, information, and training that will be required to properly support their Win2K network environment on a day-to-day basis. New Tools for New Times

To effectively support Win2K networks, administrators need to engage in additional network management activities 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 monitored alongside these other metrics. These elements, which collectively comprise Win2K’s core infrastructure, include items such as domain controllers, Active Directory databases and services, the Global Catalog, intra- and inter-site replication, site links, and DNS servers. Because Win2K and Win2K-centric applications rely heavily on these services and components for proper network operation, network administrators must be able to guarantee not only their general availability, but an acceptable baseline of performance as well. Failure to do so can result in Chapter 1

2

www.netpro.com

severe, network-wide problems including slow or failed user logon authorizations, failed convergence of directory data, the inability to access critical applications, printing problems, and similar maladies. These problems are of particular concern for IT shops that offer service-level agreements (SLAs) to their corporate parents or clients. To be able to properly maintain their Win2K infrastructure, IT shops will need not only Win2K-aware monitoring and management tools, but specific knowledge about what needs to be monitored, what thresholds must be set to maintain acceptable levels of performance, and what needs to be done in the event that problems should occur. Meet Active Directory Of all of the elements that comprise a Win2K network, the most important by far is the Active Directory, Win2K’s centralized directory service. However, before we delve into the specifics of Win2K and the Active Directory, let’s first define some of the fundamental terms and concepts related to directory-enabled networks. A directory (which is sometimes also referred to as a data store) maintains data about objects that exist within a network, in a hierarchical structure, making the information easier to understand and access. These objects include traditional network resources such as user and machine accounts, shared network resources (such as shared directories and printers), as well as resources such as network applications and services, security policies, and virtually any other type of object an administrator or application wishes to store within the directory data store. As we discussed earlier, a directory service is a composite term that includes both the directory data store as well as the services that make the information within the directory available to users and applications. Directory services are available in a variety of different types and from different sources. Operating system directories, such as Microsoft’s Active Directory and Novell’s NDS, are general purpose directories included with the network operating system and are designed to be accessible by a wide array of users, applications, and devices. There are also some applications, such as enterprise resource planning systems, human resource systems, and e-mail systems (e.g. Microsoft Exchange 5.x) that provide their own directories for storing data specific to the functionality of those applications.

Microsoft Exchange 2000 is a notable exception to this and is completely integrated with Active Directory. Exchange 2000’s installation process extends Active Directory’s structure to accommodate Exchange-specific data and subsequently uses AD to store its own directory information.

Active Directory is Microsoft’s directory service implementation in the Win2K Server operating system. The Active Directory is hosted by one or more Win2K domain controllers, and is replicated in a multi-master fashion between those domain controllers to ensure greater availability of the directory and network as a whole.

The term multi-master indicates that multiple read/write copies of the database exist simultaneously, on each Win2K domain controller computer. Thus, each Win2K domain controller is effectively an equal peer of the other controllers, and any controller can write directory updates and propagate those updates to other controllers. This is in notable contrast to NT 4.0’s single-master PDC/BDC replication topology wherein a single domain controller, the PDC, houses a read/write copy of the database.

In addition to providing a centralized repository for network objects and a set of services for accessing those objects, Active Directory also provides security in the form of access control lists (ACLs) on directory objects that protect those objects from being accessed by unauthorized parties.

Chapter 1

3

www.netpro.com

The AD Database At a file system level, the Active Directory uses Microsoft’s Extensible Storage Engine (ESE) to store the directory database. Administrators familiar with Microsoft Exchange Server may recognize this as the same database technology used in that product. Like Exchange Server, Active Directory’s database employs transactional logging files to help ensure database integrity in the case of power outages and similar events that interfere with the successful completion of database transactions. In addition, Active Directory also shares Exchange’s ability to perform on-line database maintenance and defragmentation. At the file level, AD stores its database in a single database file named Ntds.dit, a copy of which can be found on every Win2K domain controller. Although the building blocks that make up the Active Directory are largely masked by the directory’s high-level management interfaces and APIs, the physical aspects of the directory are nonetheless an important consideration for Win2K administrators. For example, it is critical that all volumes on domain controllers hosting the Active Directory database and its transaction logs maintain adequate levels of free disk space at all times. For performance reasons, it is also important that the Active Directory databases on these machines not become too heavily fragmented. Because Active Directory is a database, this effectively turns Win2K domain controllers into critical database servers on the network. These servers should therefore be treated no differently than any other important database server in terms of fault tolerance preparation (e.g. disk redundancy, backups, and power protection) and capacity planning. Logical Architecture of AD To gain an appreciation for and understanding of AD and AD management concepts, it’s important to first understand AD’s logical architecture. In this section, we’ll discuss the most important concepts associated with AD, concepts which form the foundation of all Win2K networks. Objects and Attributes

Just as the primary item of storage in a file system is a file, the primary item of storage in the Active Directory is an object. Objects can take many different forms; for example, users, computers, and printers all exist as objects within the directory. However, other items you might not immediately think of are also stored as objects; for example, policies that define which applications a particular group or user should have on their computer. 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 directory. Each class has a set of attributes that define the properties associated with that class. For example, Active Directory has a user class with attributes like First Name, Address, etc. There are special types of objects in AD known as container objects that you should be familiar with. Put simply, container objects are objects that may contain other objects. This design allows you to organize a tree or hierarchy of objects. Examples of container objects include organizational unit (OU) and domain objects. Container objects may hold both objects and/or other container objects. For example, an OU object can contain both regular objects such as users and computers, as well as other OU container objects.

Although it’s perfectly acceptable to say "create" in lieu of "instantiate" when referring to the generation of a new object within the directory, we’ll use the latter more frequently in this book. The reason is that ‘instantiate’ is more appropriate when you consider the underlying event that actually occurs -- that being the "creation of an instance of" an object. And, hey, let’s face it: saying ‘instantiate’ sounds a lot cooler and is more likely to impress people (just kidding – if we really believed that we’d start throwing around words like orthogonal!)

Chapter 1

4

www.netpro.com

The Schema

As you might imagine, all of the object classes and attributes discussed thus far have some kind of underlying reference that describes them -- a sort of "dictionary" for Active Directory. In Win2K parlance, this "dictionary" is referred to as the schema. The Active Directory schema contains the definitions of all object types that may be instantiated within the directory. Even the Active Directory schema itself is stored in the directory as objects. That is, AD classes are stored as objects of the class "classSchema" and attributes are stored as objects of class "attributeSchema". The schema, then, is just a number of instances of the classes "classSchema" and "attributeSchema", with properties that describe the relationship between all classes in the AD schema.

To understand the relationship between object classes, objects, and the schema, let’s go back to the object-oriented model upon which the AD schema is based. As is the case with object-oriented development environments (e.g. C++, Java, etc.), a class is a kind of basic definition of an object. When I instantiate an object of a certain class, I create an instance of that particular object class. That object instance has a number of properties associated with the class from which it was created. For example, suppose I create a class called "motorcycle", which has attributes like "color," "year," "enginesize," etc. I can instantiate the class "motorcycle" and create a real object called "Yamaha YZF600R6" with properties like "red" (for the color attribute), 2000 (for the year), and 600 (for the motorcycle engine’s size in CCs). Similarly, an Active Directory implementation within your enterprise is just the instantiation of the Active Directory schema classes and attributes into hundreds or thousands of different object classes and their associated attributes. For example, I might create an object of the class user called Craig Daily, who has properties like password, address, home directory location, etc. You can view the AD Schema through the AD Schema Microsoft Management Console (MMC) snap-in, which is shown in Figure 1.1.

Figure 1.1: Viewing the Active Directory Schema using the AD Schema MMC snap-in.

Chapter 1

5

www.netpro.com

Viewing the AD Schema Some of you may be curious at this point how to use the AD Schema MMC snap-in shown in Figure 1.1 to view the AD schema. It’s not immediately obvious how to do this using the MMC console, since AD Schema isn’t available in the default list of snap-ins that appears. One note of caution here: editing the schema is a potentially dangerous activity—you need to know exactly what you’re doing and why you’re doing it. Before you make schema changes, be sure to back up the current AD database contents and schema (e.g., by using ntbackup.exe or a third-party utility’s System State backup option on an up-to-date domain controller). To view the AD schema, use the Microsoft Management Console (MMC) Active Directory Schema snap-in, which you’ll find among Win2K’s Support Tools. (You can install these tools from the Win2K CD-ROM’s \support folder.) To use this snap-in, you need to manually register the snap-in by selecting Start, Run (or entering a command-prompt session) and typing: regsvr32 schmmgmt.dll You’ll receive a message stating that the OS successfully registered the .dll file. You can now load and use the Active Directory Schema snap-in through the MMC utility (i.e., mmc.exe). For example, you can open an MMC session and choose Add/Remove Snap-in from the Console menu, then select Active Directory Schema from the Add Standalone Snap-In dialog box (Figure 1.1 shows the Active Directory Schema snap-in’s view of the AD schema). To modify the AD schema, you need to use a different utility: the MMC ADSI Edit snap-in. ADSI Edit is essentially a low-level AD editor that lets you view, change, and delete AD objects and object attributes. In terms of usefulness and potential danger, ADSI Edit is to AD what the regedit or regedt32 registry editors are to the system registry. To use the ADSI Edit utility to make schema modifications, you first need to be a member of the Schema Admins group. The Schema Admins group is a universal group in native-mode Win2K domains, and it’s a global group in mixed mode Win2K domains (i.e. those which still are still running NT 4.0 domain controllers or which have no more NT domain controller but haven’t yet been converted to Win2K’s native mode). To use the snap-in, first register the associated adsiedit.dll file at the command line: regsrv32 adsiedit.dll The ADSI Edit snap-in will be available from the MMC’s Console/Add/Remove snap-in menu. Once you’ve added the snap-in, you can use the ADSI Edit console to make changes to AD objects and attributes.

For a more advanced discussion of the AD schema and its underlying constructs, I recommend The Definitive Guide to Win2K Administration by Sean Daily and Darren Mar-Elia. Chapter 1 of this book describes advanced AD schema design and management issues. You can find a link to this free eBook by Realtimepublishers.com at http://www.realtimepublishers.com.

LDAP

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.

Chapter 1

6

www.netpro.com

Active Directory supports LDAP versions 2 and 3.

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. Attribute Type

DN Abbreviation

Description

Domain-Component

DC

An individual element of the DNS domain name of the object’s domain; e.g. com, org, edu, realtimepublishers, microsoft, etc.

Organizational-Unit-Name OU

An organizational unit container object within an AD domain.

Common-Name

CN

Any object other than domain components and organizational units, such as printers, computers, users, etc.

Organization-Name

O

The name of a single organization, such as a company. Although part of the X.500 and LDAP standards, Organization is generally not used in directories such as 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.

Table 1.1. LDAP name components.

For example, the LDAP name for the user object for a person named "David Templeton" in the realtimepublishers.com domain’s Marketing OU would be as follows: CN=David Templeton,OU=Marketing,DC=realtimepublishers,DC=com The above form of an object’s name as it appears in the directory is referred to the object’s distinguished name (DN). Alternately, an object can also be referred to using its relative distinguished name (RDN). The RDN is the portion of the DN that refers to the target object within its container. In the above example, the RDN of the user object would simply be ‘David Templeton.

Chapter 1

7

www.netpro.com

Domains, Trees, and Forests

A significant advantage of AD is that it allows for a flexible, hierarchical design. To facilitate this design, the AD structure employs several different logical components. The first of these components is the domain. A domain serves as the core unit in AD’s logical structure, and is defined as a collection of computers that share a common directory database. In fact, this definition is basically identical to that of NT domains. Like NT domains, Win2K domains have unique names. However, unlike the NetBIOS-based domain names used in NT, Win2K domains use a DNS naming structure (e.g. realtimepublishers.com or mydomain.org). Domains also have several other important characteristics. First, they act as a boundary for network security: each domain has its own separate and unique security policy, which defines things such as password expiration and similar security options. Domains also act as an administrative boundary, since administrative privileges granted to security principals within a domain do not automatically transfer to other domains within AD. Finally, domains act as a unit of replication within Active Directory: since all servers acting as domain controllers in a Win2K domain replicate directory changes to one another, they contain a complete set of the directory information related to their domain.

Win2K domain names don’t have to be Internet-registered domain names ending in Internet-legal top-level domains, such as .com, .org, .net, etc. For example, it is possible to name domains with endings such as .priv, .msft, or some other ending of your choosing. This of course assumes that the domain’s DNS servers aren’t participating in the Internet DNS namespace hierarchy (which is by far the most common scenario, due to security considerations with exposing internal DNS servers to the Internet). If you do elect to use standard Internet top-level domains in your Win2K domain names, you should register these names on the Internet even if they don’t participate in the Internet DNS namespace. The reason for this is that most organizations are connected to the Internet, and using unregistered internal domain names that may potentially be registered on the Internet could cause name conflicts.

Win2K’s AD design also integrates the concepts of forests and trees. A tree is a hierarchical arrangement of Win2K domains within AD that forms a contiguous namespace. For example, assume a domain named xcedia.com exists in your AD structure. The two subdivisions of xcedia.com are Europe and us, which are each represented by separate domains. Within AD, the names of these domains would be us.xcedia.com and europe.xcedia.com. These domains would form a domain tree since they share a contiguous namespace. This arrangement demonstrates the hierarchical structure of AD and its namespace: all of these domains are part of one contiguous related namespace in the directory; that is to say, they form a single domain tree. The name of the tree is the root level of the tree, in this case, xcedia.com. Figure 1.2 shows the single-domain tree described in this example.

Chapter 1

8

www.netpro.com

Figure 1.2: An Active Directory forest with a single tree.

A forest is a collection of one or more trees. A forest can be as simple as a single Win2K domain, or more complex such as a collection of multi-tiered domain trees. Let's take our single-tree example scenario from earlier a step further. Assume that within this AD, the parent organization Xcedia also has a subsidiary company with a Win2K/DNS domain name of Realtimepublishers.com. Although the parent company wants to have both organizations defined within the same AD forest, it wants their domain and DNS names to be unique. To facilitate this, you would define the domains used by the two organizations within separate trees in the same AD forest. Figure 1.3 illustrates this scenario. All domains within a forest (even those in different trees) share a schema, configuration, and global catalog (we’ll discuss the global catalog in a later section). In addition, all domains within a forest automatically trust one another due to the transitive, hierarchical Kerberos trusts that are automatically established between all domains in a Win2K forest.

The Kerberos Version 5 authentication protocol is a distributed security protocol based on Internet standards, and is the default security mechanism used for domain authentication within or across Win2K domains. Kerberos replaces Windows NT LAN Manager (NTLM) authentication used in Windows NT Server 4.0, as the primary security protocol for access to resources within or across Win2K Server domains. Win2K domain controllers still support NTLM to provide backward compatibility with Windows NT 4.0 machines.

Chapter 1

9

www.netpro.com

Figure 1.3: Example of a multi-tree Active Directory forest.

In the case of a forest with multiple trees, the name of the forest is the name of the first domain created within the forest (i.e. the root domain of the first tree created in the forest).

Although cohabitation of different organizations within the same AD forest is appropriate in some circumstances, in others it is not. For example, unique security or schema needs may require two companies to use entirely different AD forests. In these situations, Kerberos trusts aren’t established between the two forests but you may create explicit trusts between individual domains in different forests.

There are several resources you might find helpful when planning your organization’s AD structure and namespace. One is The Definitive Guide to Active Director y Design and Planning, another free eBook from Realtimepublishers.com (a link to which can be found at http://www.realtimepublishers.com). There are also several Microsoft white papers that contain valuable information on AD design and architectural concepts, including "Active Director y Architecture" and "Domain Upgrades and Active Director y." These and others technical documents related to AD can be found on Microsoft’s Web site at http://www.microsoft.com/windows2000/ser ver.

Chapter 1

10

www.netpro.com

Organizational Units

An organizational unit (OU) is a special container object that is used to organize other objects – such as computers, users, and printers – within a domain. OUs can contain all of these object types, and even other OUs (this type of configuration is referred to as nested OUs). OUs are a particularly important element of Active Directory for several reasons. First, they provide the ability to define a logical hierarchy within the directory without creating additional domains. OUs allow domain administrators to subdivide their domains into discrete sections and delegate administrative duties to others. More importantly, this delegation can be accomplished without necessarily giving the delegated individuals administrative rights to the rest of the domain. As such, OUs facilitate the organization of resources within a domain.

There are a number of models used for the design of OU hierarchies within domains, but the two most common are those dividing the domain organizationally (e.g. by business unit) or geographically.

An example of OUs within a domain is shown in Figure 1.4.

Figure 1.4: Organizational units (OUs) within a domain.

The Global Catalog

Because Active Directory is the central component of a Win2K network, network clients and servers frequently query it. In order to increase the availability of Active Directory data on the network as well as the efficiency of directory object queries from clients, Win2K introduces a service known as the global catalog. The global catalog is a separate database from the Active Directory itself, and contains a partial, read-only replica of all the directory objects in the entire AD forest. Only Win2K servers acting as domain controllers may be configured as global catalog servers. By default, the first domain controller in a Win2K forest is automatically configured to be a global catalog server (this can be moved later to a different domain controller if desired; however, every Win2K forest must contain at least one global catalog). Like Active Directory itself, the global catalog uses replication in order to ensure updates between the various global catalog servers within a Win2K domain or forest. In addition to being a repository of commonly queried AD object attributes, the global catalog plays two primary roles on a Win2K network:

Chapter 1

11

www.netpro.com

Network logon authentication

In native-mode Win2K domains (networks where all domain controllers have been upgraded to Win2K and the native mode election has been manually made by the administrator), the global catalog facilitates net work logons for Active Directory-enabled clients. It does so by providing universal group membership infor mation to the account sending the logon request to a domain controller. This applies not only to regular users but also to every type of object that must authenticate to the Active Directory (including computers, etc.). In multi-domain networks, at least one domain controller acting as a global catalog must be available in order for users to log on. Another situation that requires a global catalog server occurs when a user attempts to log on with a user principal name (UPN) other than the default. If a global catalog server is not available in these circumstances, users will only be able to login to the local computer (the one exception is members of the domain administrators group, who do not require a global catalog server in order to log on to the network). Directory searches and queries

With Active Directory, read requests such as directory searches and queries by far tend to outweigh writeoriented requests such as directory updates (e.g. by an administrator or during replication). The majority of Active Directory-related network traffic on a Win2K network is comprised of requests from users, adminis trators, and applications about objects in the directory. As a result, the global catalog is essential to a Win2K infrastructure since it allows clients to quickly perform searches across all domains within a forest.

Note: Although mixed-mode Win2K domains do not require the global catalog for the network logon authentication process, global catalogs are still important in facilitating directory queries and searches on these networks and should therefore be made available at each site within the network.

Physical Structure of AD Thus far, our discussion of AD has focused on the logical components of the directory’s architecture; that is, the components used to structure and organize network resources within the directory. However, an AD-based network also incorporates a physical structure, which is used to configure and manage network traffic. Domain Controllers

The concept of a domain controller has been around since the introduction of Windows NT. As is the case with NT, a Win2K domain controller is a server that houses a replica of the directory (in the case of Win2K, the directory being AD rather than the NT SAM database). Domain controllers are also responsible for replicating changes to the directory to other domain controllers in the same domain. Additionally, domain controllers are responsible for user logons and other directory authentication, as well as directory searches.

Fortunately, Win2K does away with NT’s restriction that converting a domain controller to a member server or vice-versa requires reinstallation of the server OS. In Win2K, servers may be promoted or demoted to domain controller status dynamically (and without reinstallation) using the Dcpromo.exe domain controller promotion wizard.

Chapter 1

12

www.netpro.com

At least one domain controller must be present in a domain, and for fault tolerance reasons it’s a good idea to have more than one domain controller at any larger site (e.g. a main office or large branch office). To prevent user logon traffic from crossing over WAN links, you should consider putting at least one domain controller in even the smallest of your branch offices and similar remote sites. Directory Replication

As we’ve discussed, domain controllers are responsible for propagating directory updates they receive (e.g. a new user object or password change) to other domain controllers. This process is known as directory replication, and can be responsible for a significant amount of WAN traffic on many networks. The Win2K Active Directory is replicated in a multi-master fashion between all domain controllers within a domain to ensure greater availability of the directory and network as a whole. The term multi-master indicates that multiple read/write copies of the database exist simultaneously on each Win2K domain controller computer. Thus, each Win2K domain controller is effectively a peer of the other controllers, and any domain controller can write directory updates and propagate those updates to other domain controllers. This is in notable contrast to NT 4.0’s single-master PDC/BDC replication topology wherein a single domain controller, the PDC, houses a read/write copy of the database. AD’s replication design means that different domain controllers within the domain may hold different data at any given time – but usually only for short periods of time. As a result, individual domain controllers may be temporarily out of date at any given time and unable to authenticate a login request. Active Directory’s replication process has the characteristic of bringing all domain controllers up to date with each other; this characteristic is called "convergence".

The Operations Masters

Although multi-master replication is a central feature of Active Directory and Win2K networks, the potential for collisions and conflict between multiple servers makes this functionality inappropriate for some network operations and roles. Win2K accommodates these special cases by electing specific domain controllers to serve as operations masters (also referred to as flexible single master operations or FSMOs) for each of these network roles. There are five different types of operations masters in Win2K: two that are forest-specific and three that are domain-specific. Win2K automatically elects the operation master servers during the creation of each Active Directory forest and domain.

Chapter 1

13

www.netpro.com

When you use the Active Directory Installation Wizard to create the first domain in a new forest, all five of the ]single master operations roles are automatically assigned to the first domain controller in that domain. In a small Active Directory forest with only one domain and one domain controller, that domain controller continues to own all the operations master roles. In a larger network, whether with one or multiple domains, you can re-assign these roles to one or more of the other domain controllers. The two forest-specific operations master roles are listed below: Schema master

The domain controller that serves the schema master role is responsible for all updates and modifications to the forest-wide Active Directory schema. The schema defines every type of object and object attribute that can be stored within the directory. Modifications to a forest’s schema can only be done by members of the Schema Administrators group, and can be done only on the domain controller that holds the schema master role. Domain naming master

The domain controller elected to the domain naming master role is responsible for making changes to the forest-wide domain name space of the Active Directory. This domain controller is the only one that can add or remove a domain from the directory, or add/remove references to domains in external directories. The three domain-specific operations master roles are as follows: PDC emulator

If a Win2K domain contains non-AD-enabled clients or is a mixed-mode domain containing Windows NT backup domain controllers (BDCs), the PDC emulator acts as a Windows NT primary domain controller (PDC) for these systems. In addition to replicating the Windows NT-compatible portion of directory updates to all BDCs, the PDC emulator is also responsible for time synchronization on the network (which is important for Win2K’s Kerberos security mechanism), and processing account lockouts and client pass word changes. RID master

The RID (relative ID) master allocates sequences of RIDs to each domain controller in its domain. Whenever a Win2K domain controller creates an object such as a user, group, or computer, that object must be assigned a unique security identifier (SID). A SID consists of a domain security ID (this is identical for all SIDs within a domain), and a RID. When a domain controller has exhausted its internal pool of RIDs, it requests another pool from the RID Master domain controller. Infrastructure master

When an object in one domain is referenced by an object in another domain, it represents the reference by the Globally Unique IDentifier (GUID), the Security IDentifier (SID – for objects that reference security principals), and the Distinguished Name (DN) of the object being referenced. The infrastructure master is the domain controller responsible for updating an object's SID and distinguished name in a cross-domain object reference. The infrastructure master is also responsible for updating all inter-domain references any time an object referenced by another object moves (for example, whenever the members of groups are renamed or changed, the infrastructure master updates the group-to-user references). The infrastructure master distributes updates using multi-master replication. Note: except where there is only one domain controller in a domain, never assign the infrastructure master role to the domain controller that is also acting as a global catalog server. If you use a global catalog server, the infrastructure master will not function properly. Specifically, the effect will be that cross-domain object references in the domain will not be updated. In a Chapter 1

14

www.netpro.com

situation where all domain controllers in a domain are also acting as global catalog servers, the infrastructure master role is unnecessary since all domain controllers will have current data. Because the operations masters play such critically important roles on a Win2K network, it’s essential for proper network operation that all the servers hosting these roles are continually available. Sites

The final, and perhaps most important component of AD’s physical structure is a site. Sites allow administrators to define the physical topology of a Win2K network, something that wasn’t possible under Windows NT. Sites can be thought of as areas of fast connectivity (e.g. individual office LANs), but are defined within AD as a collection of one or more IP subnets. When you look at the structure of the IP protocol, this begins to make sense – different physical locations on a network are typically going to be connected by a router, which in turn necessitates the use of different IP subnets on each network. It’s also possible to group multiple, non-contiguous IP subnets together to form a single site. So, why are sites important? The primary reason is that the definition of sites makes it possible for AD to gain some understanding of the underlying physical network topology, and tune replication frequency and bandwidth usage accordingly (under NT, this could only be done via manual adjustments to the replication service). This "intelligence" conferred by the knowledge of the network layout has numerous other benefits. For example, it allows AD-enabled computers hosting users who are logging into the network to automatically locate their closest domain controller and use that controller to authenticate. This helps prevent a situation commonly seen under NT, wherein logon authentication requests often traverse low-bandwidth WAN connections to remote domain controllers in situations where the local domain controller is temporarily busy and the client computer has erroneously cached the faraway controller as the default controller to use for logons. In a similar fashion, sites also give other components within a Win2K network new intelligence. For example, a client computer connecting to a server running the Distributed File System (Dfs) feature in Win2K can use sites to locate the closest DFS replica server. It’s important to remember that sites are part of the physical structure of AD and are in no way related to the logical constructs we’ve already discussed, such as domains and OUs. It’s possible for a single domain to span multiple sites, or conversely for a single site to encompass multiple domains. The proper definition of sites is an essential aspect of AD and Win2K network design planning.

For sites that house multiple domains (e.g. an organization that divides business units into domains rather than OUs, thus hosting multiple business unit domains on a single site), it’s important to remember to place at least one, and possibly two, domain controllers for each domain that users will authenticate to from that site. This outlines the biggest disadvantage of the business unit domain model: the potential for requiring many domain controllers at each and every site.

Chapter 1

15

www.netpro.com

AD’s Backbone: DNS The TCP/IP network protocol plays a far larger role in Win2K than with previous versions of Windows NT. Although other legacy protocols such as IPX and NetBEUI continue to be supported, most of the internal mechanics of Win2K networks and Active Directory are based on TCP/IP. In Win2K, as with all TCP/IP-based networks, the ability to resolve names to IP addresses is an essential service. A bounded area within which a given name can be resolved is referred to as a namespace. In Windows NT-based networks, NetBIOS is the primary namespace, and WINS the primary name-to-IP address resolution service. With Win2K, Microsoft has abandoned the use of NetBIOS as the primary network namespace and replaced it with DNS, which is also used on the Internet. Like Active Directory, DNS provides a hierarchical namespace. Both systems also make use of domains, although they define them somewhat differently. Computer systems (called "hosts") in a DNS domain are identified by their fully qualified domain name (FQDN), which is formed by appending the host’s name to the domain name within which the host is located. Multi-part domain names (i.e. domains that are several levels deep in the hierarchy of the DNS namespace) are listed with most important domain division (e.g. .com, .org, .edu, etc.) at right and the least important – the host name – at left. In this way, a host system’s FQDN indicates its position within the DNS hierarchy. For example, the FQDN of a computer named ‘mercury’ located in the domain ‘realtimepublishers.com’ would be mercury.realtimepublishers.com. Although it is possible to incorporate a DNS namespace within a Windows NT network for name-to-IP address resolution, the use of DNS is optional and mainly of interest to enterprises running in heterogeneous environments or Internet-based applications. However, DNS plays a far more critical role in the Win2K Active Directory. In Win2K, DNS replaces NetBIOS as the default name resolution service (however, it is still possible to continue using a NetBIOS namespace and WINS servers on a Win2K network for legacy systems and applications). In addition, Win2K domains use a DNS-style naming structure (e.g. a Win2K domain might have a name such as ‘santarosa.realtimepublishers.com’ or ‘mydomain.net’), which means the namespace of Active Directory domains is directly tied to that of the network’s DNS namespace. This namespace duplication will normally be limited to the internal DNS namespace for companies using the Microsoft-recommended configuration of separate DNS configurations for the internal LAN and the Internet.

Chapter 1

16

www.netpro.com

Finally, Win2K and Active Directory use DNS as the default locator service; that is, the service used to convert items such as Active Directory domain, site, and service names to IP addresses. It’s important to remember that although the DNS and Active Directory namespaces in a Win2K network are identical in regards to domain names, the namespaces are otherwise unique and used for different purposes. DNS databases contain domains and the record contents (e.g. host address/A records, server resource/SRV records, mail exchanger/MX records, etc.) of the DNS zone files for those domains, whereas the Active Directory contains a wide variety of different objects including domains, organizational units, users, computer, and group policy objects. Another notable connection between DNS and the Active Directory is that Win2K DNS servers can be configured to store their DNS domain zone files directly within the Active Directory itself, rather than in external text files. Although DNS doesn’t rely on the Active Directory for its functionality, the converse is not true: Active Directory relies on the presence of DNS for its operation. Win2K includes an implementation of Dynamic DNS (defined by RFC 2136) that allows AD-enabled clients to locate important Win2K network resources, such as domain controllers, through special DNS resource records called SRV records. The accuracy of these SRV records is therefore critical to the proper functioning of a Win2K network (not to mention the availability of the systems and services they reference).

Introduction to AD and Win2K Monitoring As you’ve already learned, Win2K introduces a number of new and important infrastructure components that did not exist in Windows NT networks. As a result, ensuring the health and availability of your Win2K servers means that you will need to account for these additional components in your network monitoring routine. Monitoring will provide early warning indicators that will help mitigate the risk of loss associated with network downtime. The network monitoring procedures employed by most organizations tend to fall into one of the following categories: Limited or no proactive monitoring procedures in place.

Unfortunately, IT departments in some organizations are purely reactive when it comes to network infra structure problems, and either do not regularly monitor critical network resources and components, or have limited monitoring in place. Some may conduct regular reviews of server event logs or generate reports based on these logs, but since such information is delivered in an on-demand fashion, it is of diminished value when compared to real-time monitoring systems. These organizations will be at high risk of down time and financial loss in a Win2K environment. Existing monitoring procedures in place using home-grown or built-in tools.

A second category is where the need for proactive network monitoring is recognized, but has been imple mented by the organization using basic, low-cost tools (e.g. shareware/freeware utilities or those provided with the OS or the Resource Kit). This includes tools such as Event Viewer and Performance Monitor, Resource Kit utilities (e.g. NLTEST, BROWMON, NETDOM, DOMMON, DATALOG, REPADMIN, REPLMON, DFSCHECK, and similar utilities), and freeware/shareware utilities (e.g. utilities that test machine and service availability using PING, NT service status queries, and queries to well-defined ports such as DNS, HTTP, and FTP, etc.) Although all of these tools can be helpful in ensuring network health, many require high levels of attention from administrators and suffer from significant limitations when it comes to scalability and identifying the various types of problems that may exist on the network.

Chapter 1

17

www.netpro.com

Existing monitoring procedures in place with full-featured network monitoring tools.

The third category is organizations with network monitoring routines built on sophisticated, full-featured network monitoring software. In addition to many of the basic services provided by the tools that come with Windows NT/2000, the Resource Kits, and freeware/shareware utilities, these utilities typically include intel ligent scripting to provide sophisticated testing as well as corrective actions in the event of failure. In addi tion, many network-monitoring tools include a knowledge base that helps administrators understand why a problem is happening and offer suggestions as to how to resolve it. For organizations running large or multisite Win2K networks, this type of tool is highly recommended. For administrators of Windows NT (or other operating systems) networks that have existing monitoring tools and procedures, the migration to Win2K will mainly involve an upgrade of existing tools and staff knowledge about the vulnerabilities of the new environment. However, if your organization has employed a more reactive stance (i.e. fix it only when it breaks) with regards to resolving network problems, you’ll quickly find that this methodology can be especially troublesome in a Win2K environment. Although it is true that Win2K provides a far greater level of reliability and performance than its predecessors, it also involves a higher number of "moving parts" and dependencies that need to be accounted for. Although legacy Windows NT networks have their own set of dependencies and vulnerabilities, they are far fewer in number due to NT’s simpler (and less capable) network architecture. Let’s quickly review the primary monitoring considerations in a Windows NT environment are as follows: PDC availability and performance

Due to the single-master nature of NT domains, there is a high dependence (and thus, a high availability requirement) on the Primary Domain Controller (PDC) of each Windows NT domain. Although Backup Domain Controllers exist to create fault-tolerance and load-balancing for client logon authentication, a Windows NT domain without a PDC essentially grinds to a halt until the PDC is brought back online or replaced via the manual promotion of a BDC to PDC status by a network administrator. In addition, net work logon traffic loads on domain controllers should be monitored to assess domain controller perform ance and the ability to respond to client network logon authentication requests within an acceptable period of time. Domain trust relationships

On multi-domain NT networks, there typically exists a complex array of trust relationships between domains in order to accommodate network access requirements for the business. NT trust relationships (formed between domain controllers) are notoriously fragile and prone to failure, and thus require continual monitoring and testing in order to assure the availability of network resources to users. Name servers

Another aspect of NT networks requiring continual monitoring is the availability of network name servers. For the majority of Windows NT-based networks (including those with Windows 95/98/ME/2000 clients), NetBIOS is the predominant namespace and Windows Internet Name Service (WINS) the predominant name-to-IP address resolution service. WINS databases and replication are also notoriously fragile elements of NT networks, and must be regularly monitored to ensure their functionality. Even for networks using DNS as the primary name resolution service, the availability of the DNS name servers is equally important as it is with WINS.

Chapter 1

18

www.netpro.com

Network browser service

Windows NT, Windows Me, Windows 98, Windows 95, and other members of the Windows product family rely on a network browsing service to build lists of available network resources (e.g. servers, shared directories, and shared printers). The architecture of this service, which calls for each eligible network node to participate in frequent elections to determine a browse master and backup servers for each network segment is another infamously unreliable aspect of Microsoft networks and which requires frequent attention and maintenance. Other critical services and applications

In addition to name resolution services such as WINS and DNS, NT environments may house other mission-critical services required for proper operation of the network or the business in question. For example, critical applications such as backup, antivirus, mail, FTP, web, and database servers should be polled using intelligent service-level queries to verify that they are functioning properly and at acceptable levels of performance. Basic network and system metrics

All networks, Windows NT or otherwise, should be monitored to protect against problems stemming from resource allocation problems on individual servers or the network itself. For example, any good network monitoring regimen will include the monitoring of CPU, memory, and disk space resource usage on all critical servers, as well as network connectivity and bandwidth usage. AD and Win2K Monitoring Considerations

A functioning Win2K network is a complex mesh of relationships and dependencies involving a variety of different systems and services, including Active Directory, DNS, the global catalog, and operations master servers. Running an effective Win2K network means having a handle of every aspect of your network environment at all times. It’s no surprise that the primary monitoring consideration in Win2K is Active Directory and its related services and components. This includes responsiveness to DNS and LDAP queries, AD inter-site and intra-site replication, and a special Win2K service called the Knowledge Consistency Checker (KCC). In addition, the health and availability of services such as DNS, the global catalog, and DFS are also important.

The Knowledge Consistency Checker (KCC) is a special Win2K service that automatically generates Active Directory’s replication topology, and ensures that all domain controllers on the network participate in replication.

However, knowing what metrics to monitor is only a first step. By far, the most important and complex aspect of monitoring network health and performance isn’t related to determining what to monitor, but rather how to digest the raw data collected from the array of metrics and make useful determinations from that data. For example, although it would be possible to collect data on several dozen metrics (e.g. via Performance Monitor) related to Active Directory replication, simply having this information at hand doesn’t tell you how to interpret the data, or what you should consider acceptable tolerance ranges for each metric. A useful monitoring system not only collects raw data, but also understands the inter-relation of that data and how to use the information to identify problems on the network. This kind of artificial intelligence represents the true value of network monitoring software.

Chapter 1

19

www.netpro.com

In order to ensure the health and availability of the Active Directory as well as other critical Win2K network services, organizations will need to regularly monitor a number of different services and components, which are listed in Table 1.2. Category

Potential Problems

Domain Controllers/Active Directory

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

Chapter 1

20

www.netpro.com

DNS

Missing or incorrect SRV records for domain controllers Slow or failed DNS query responses DNS server zone file update failures

Operation Masters (FSMOs)

Inaccessibility of one or more operation master (FSMO) servers (PDC emulator, RID allocation, Infrastructure, Domain Naming, Schema) Forest or domain-centric operation master roles not consistent across domain controllers within domain/forest Slow or failed role master responses

Miscellaneous Problems

Low-level network connectivity problems TCP/IP routing problems DHCP IP address allocation pool shortages WINS server query or replication failures (for legacy NetBIOS systems and applications) Naming context lost + found items exist Application or service failures or performance problems

Table 1.2: Common Problems in Active Directory-based Win2K Networks.

Change Monitoring and Auditing

In addition to monitoring and troubleshooting problems within the Win2K network infrastructure, another distinct advantage of monitoring software is the ability to monitor and audit changes made to the Active Directory database. In many organizations, there may be dozens or even hundreds of administrators making daily changes to the Active Directory. In order to manage the potential chaos this situation presents, it’s essential that a system be in place to identify all recent changes made to objects within the directory, and to be able to ascertain who did what – and when. Examples of the kinds of changes that you might want to track include changes to the Active Directory schema, OUs, contacts, computers, printers, and directory recovery actions taken by administrators (e.g. a site administration restoring Active Directory on a local domain controller). Problem Resolution, Automation, and Alerting

Monitoring and troubleshooting critical network infrastructure components is an important starting point, but it is by no means the only proactive measure that you can take to increase the availability of your network. Good network monitoring software provides a wide assortment of alerting options, such as console alerts, network pop-up messages, event log entries, e-mail alerts, pager notifications, and SNMP traps. In addition to providing problem identification and alerting features, many third-party products also provide automatic problem resolution features. For example, it is possible to configure many products to take specific corrective actions when a problem is detected, such as restarting a particular service when it is found to be unresponsive.

Chapter 1

21

www.netpro.com

Many tools use scripting and/or the ability to call external utilities to accomplish these tasks. The most comprehensive utilities base their decisions on rule sets derived from an internal database and/or intelligent escalation routines that emulate what an administrator might do. For example, you might configure a system such that on the first failure of a given service, that service is restarted; the computer is restarted in the event the service restart fails; a different machine is promoted to replace that system in the event the computer restart attempt fails, and so on. Other Considerations

There are several considerations you should keep in mind when creating a Win2K network monitoring and troubleshooting solution. One is the overall architecture of the application(s) being used in the solution. It’s important to understand how the product collects its data and what impact this collection will have on your network and servers. For example: Does the product employ local agents to gather metrics or does it use remote queries? Do throttling features exist to control network bandwidth and system resource usage? Is there a machine/site/domain hierarchy that allows data to be passed to the central collection database in an efficient manner? Does the product provide web-based management? All of these questions are important since they can have a significant impact on your network environment and your overall satisfaction with the product. Another differentiating feature about network monitoring software packages is whether or not they provide a support knowledgebase of common problems and solutions. This kind of knowledge is invaluable from both a technical and financial standpoint, since it serves to reduce the learning curve of the supporting IT staff, as well as the amount of time and money administrators must expend researching and resolving problems. Some utilities augment this capability by allowing administrators to add their own experience to the knowledgebase or a problem tracking and resolution database, thereby leveraging internal IT staff expertise and creating a comprehensive problem resolution system. A final feature provided by some applications, and one that may be of interest to IT shops engaged in Service Level Agreements (SLAs), is the ability to generate alerts and reports that address exceptions to, or compliance with SLA obligations. Summary Although Win2K and Active Directory represent a quantum leap forward in the NT product line, they also introduce new levels of network infrastructure complexity that must be properly managed in order to maintain an efficient and highly available network. Real-time, proactive monitoring and management of the Active Directory and other critical services is an essential part of managing Win2K-based networks. In this chapter, we discussed the most important features and components of Win2K and Active Directory, their roles within the enterprise, differences between managing Windows NT 4.0-based networks and Win2K Active Directory-based networks, and some of the basic metrics and statistics that Win2K network administrators need to watch to help them ensure high availability on their networks. In the remaining chapters of this book, we’ll drill down and explore each of the vital areas of Active Directory and Win2K networks in detail, providing the information, tools, and techniques you’ll need to employ to maintain a healthy and highly available Win2K network. eBook Copyright Notice This site contains materials created, developed, or commissioned by Realtimepublishers.com, Inc. and is protected by international copyright and trademark laws. No material (including but not limited to the text, images, audio, and/or video) may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at [email protected] Chapter 1

22

www.netpro.com

Chapter 2

The Definitive Guide to Active Directory Troubleshooting

Designing an Effective Active Directory The main function of Active Directory (AD) is to allow the network resources for Windows 2000 (Win2K) to be identified and accessed. AD accomplishes this goal by providing a single namespace where users and applications can go to register and gain access to the information they need. AD can be set up and designed in many different ways to meet the needs of users and administrators. It’s your job as an administrator to properly set up and design your AD for maximum efficiency. The best way to troubleshoot AD problems is to avoid AD problems in the first place. To do that, you need to start with a good design. The design of AD not only includes the layout of the forests, trees, domains, and Organizational Units (OUs) but also the site and site links that represent the physical network. In this chapter, I’ll give you a solid understanding of how to design an AD for your environment and network. Because the information in AD can be distributed across the network, there may be unique aspects of your design and implementation that only apply to your site. However, my goal is to give you enough information to ensure that the design serves the needs of your users and administrators.

Active Directory’s Logical and Physical Structures As I mentioned in Chapter 1, AD has internal structures that can be categorized as logical and physical. These structures are the building blocks you’ll use to design and build your AD service. Your challenge is to understand each building block and use it to build an efficient AD. The concepts behind these structures are sometimes not easy, but understanding them and using them correctly are the keys to a good design. Logical Structures A list of logical structures used in AD is shown in Table 2.1.

Logical Structure

Description

Namespace

AD is a namespace because it resolves an object’s name to the object itself.

Naming context

Represents a contiguous subtree of AD.

Organizational Unit Domain

A container object that allows you to organize your objects and resources. 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.

Table 2.1: The logical structures of AD, which are used to design and build the object hierarchy.

Chapter 2

24

www.netpro.com

Two important logical structures that you need understand to design an AD are the namespace and naming context. Although these two concepts seem to mean the same thing, they’re actually different. To help you understand how they differ, I’ll give you a quick overview of each. These structures are also discussed throughout the chapter.

AD depends on DNS and the DNS-type namespace that names and represents the domains in the forest. It’s important to design your domain tree in a DNS-friendly way and to provide clients with reliable DNS services. Although AD uses DNS to create its structure, DNS and AD are totally separate namespaces.

Namespace

Another term for a directory is namespace. A namespace refers to a logical space in which you can uniquely resolve a given name to a specific object in the directory. AD is a namespace because it resolves a name to the object name and the set of domain servers that stores the object itself. Domain Name System (DNS) is a namespace because it translates easy-to-remember names (such as www.company.com) into an IP number address (for example, 124.177.212.34). Naming Context

The naming context represents a contiguous subtree of AD in which a given name is resolved to an object. If you look at the internal layout of AD, you see a structure that looks similar to a tree with branches. If you expand the tree, you see the containers, the objects that reside in them, and the attributes associated with the objects. In AD, a single domain controller always holds at least three naming contexts. Domain

Contains the object and attribute information for the domain of which the domain controller is a member Configuration

Contains the rules for creating the objects that define the logical and physical structure of the AD forest Schema

Contains the rules for creating new objects and attributes.

Chapter 2

25

www.netpro.com

Physical Structure

Description

Object and attributes

An object is defined by the set of attributes or characteristics assigned to it. Objects include users, printers, servers, groups, computers, and security policies. A network server that hosts AD in a domain. 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). 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. Stores the global catalog information for AD.

Domain controller Directory server role

Site

Global catalog server

Table 2.2: The physical structures of AD, which are used to implement the logical directory structures on the network

Physical Structures In addition to the logical structures in AD, several physical structures help you implement the logical structures on your network. These physical structures are listed in Table 2.2.

Designing Active Directory Your primary objective in designing AD is to build a system that reflects the network resources in your company. You need to arrange the forest and trees to reflect the location and placement of your network resources. You need to design the domains and OUs to implement an administrative and security structure for both users and administrators. When designing the layout of AD, you also need to design the users’ groups and security policies as well as the administrative methods you used. From the list of logical and physical structures that you have to work with, four structures are critical to the design of AD: forests and trees, domains, OUs, and sites. Designing and implementing each of these four structures builds on the previous one. Implementing these structures properly is crucial to a successful design. Design your AD structure in the following order: 1. Design the forest and trees 2. Design the domains for each tree 3. Design the OUs for each domain 4. Design the sites for the forest and domains.

In the next four sections, I’ll describe how to design each of these main structures.

Designing the Forest and Trees A forest is a collection of one or more trees. A forest can also be a set of domain trees that doesn’t form a common naming context. The trees in a forest share the same directory schema and configuration but don’t need to share the same namespace. For example, a single directory can contain two companies or organizations. Figure 2.1 illustrates how two companies named company1.com and company2.com form a single forest.

Chapter 2

26

www.netpro.com

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

The forest serves two main purposes. First, it simplifies workstation interaction with AD because it provides a global catalog where the client can perform all searches. Second, the forest simplifies administering and managing multiple trees and domains. A forest has the following key characteristics or components: Global Schema

The directory schema for the forest is a global schema, meaning that it’s exactly the same for each domain controller in the forest. The schema exists as a naming context and is replicated to every domain controller. The schema defines the object classes and the attributes of object classes. Global Configuration Container

The configuration container exists as a naming context that is replicated to every domain controller in the forest. Thus, it’s exactly the same across the domain controllers in the forest. The configuration container contains the information that defines the structure of the forest. This information includes the domains, trust relationships, sites, site links, and the schema. By replicating the configuration container on every domain controller, each domain controller can reliably determine the structure of the forest, allowing it to replicate to the other domain controllers. Complete Trust

AD automatically creates bi-directional transitive trust relationships among all domains in a forest. This allows the security principals, such as users and groups of users, to authenticate from any computer in the forest. However, this is only true if the users’ access rights have been set up correctly. Global Catalog

The global catalog contains a copy of every object from every domain in the forest. However, it only stores a select set of attributes from the objects. By default, the global catalog isn’t placed on every domain controller in the forest; instead, you determine which domain controllers should hold a copy.

Chapter 2

27

www.netpro.com

When designing the forest, you need to consider both the users and the administrators. For example, consider an organization that has just acquired another company. If the two forests are merged into a single forest, all the users can view the entire AD. However, the forests might not be merged because the two autonomous administrative groups might not agree on how to manage the forests. The winner of this dispute depends on your priority: Do your users have a higher priority than your administrators? If the administrators win, the users inherit two forests and no longer have a single, consistent view of AD. Each administrative group manages its own forest independently. The answer also depends on which type of organization your company is. If it isn’t important for the users to have a consistent view of AD, it might be appropriate to have multiple forests with separate administrators. For example, consider an application service provider (ASP) company, which hosts AD services on behalf of other companies. The users from those companies have no reason to view the host company’s information. In addition, each administrative group wants its independence. Determining the Number of Forests When determining the number of forests for your company, consider the requirements of the organization itself. In smaller, centrally managed organizations, you typically need one forest. However, if the company is large and has multiple locations in one or multiple countries, you probably need multiple forests. To properly determine the number of forests for your company, you need to understand the maintenance and overhead of having one forest compared to multiple forests. An environment with a single forest is simple to create and maintain. All users view one AD using the global catalog. Maintaining a single forest is easy because you only need to apply configuration changes once to affect all the domains in the forest. For example, when you add a domain to the forest, all the trust relationships are set up automatically. In addition, the new domain receives any additional changes made to the forest. When deciding on the number of forests you need, remember that a forest has shared elements: the schema, configuration container, and global catalog. Thus, all the administrators need to agree on their content and management. Managing these elements becomes more complicated when you add a forest because it incurs a management cost. The following is a brief list of the many management issues surrounding multiple forests: • Each additional forest must contain at least one domain, domain controller, and someone to manage it. • Each additional forest creates a schema. Maintaining consistency among schemas is difficult and creates overhead. • Each additional forest creates a configuration container. Maintaining consistency among configuration containers when the network configuration changes is difficult and creates overhead. • If you want user access among forests, you must create and maintain explicit one-way trusts for every relationship you establish. • Users wanting access to resources outside their forest need to make explicit queries; this is difficult for the ordinary user.

Chapter 2

28

www.netpro.com

• 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.

One situation in which you may consider managing multiple forests occurs when two organizations merge or participate in a joint venture. This puts the administration of your network into the hands of two autonomous groups. For this reason, multiple trees are typically more costly to manage. To reduce this cost, organizations such as partnerships and conglomerates need to form a central group that can drive the administrative process. On the other hand, in short-lived organizations like joint ventures, it might not be realistic to expect administrators from each organization to collaborate on forest administration. There is another good example of a situation where multiple forests may be required. Many enterprise organizations elect to maintain separate, parallel AD forests for testing purposes. Other organizations maintain multiple forests because they have a disjointed organizational structure with no common infrastructure among business units. Although you’ll certainly want to keep your network and AD design as simple as possible, your forest structure should follow the organizational, administrative, and geographical structure of your organization.

Setting Up and Managing Multiple Forests

Having to set up and manage two forests might be necessary if two organizations in a company don’t trust one another or cannot agree on administrative policies. For example, let’s say a company has two locations in different countries—New York and London. Each location has its own administrative group, which needs to manage its network resources according to its own policies. In this case, two different forests can be used to separate the administrative requirements. In other situations, your company might have multiple forests, but you want to have a central administrative group. To set up central management of multiple forests, you need to add administrators to the Enterprise and Schema Administration groups of each forest. Because there is only one Enterprise and Schema Administration group per forest, you must agree on a central group of administrators who can be members of these groups. As mentioned previously, it’s difficult to manage user access between two or more forests. The simplest method is to create explicit one-way trusts among the domains that must trust one another. The one-way trust only allows access among the domains in the direction that it’s set up. This approach of connecting the forest is shown in Figure 2.2.

Chapter 2

29

www.netpro.com

Figure 2.2: Two forests can allow user access between its domains by establishing explicit one-way trusts. Only the domains connected by the trusts can allow access between the forests.

Figure 2.3: The namespace of the domain tree shows the hierarchical structure of the tree.

Chapter 2

30

www.netpro.com

Explicit one-way trusts aren’t transitive. The one-way trusts in Win2K are the same as the one-way trusts that existed in Windows NT. Creating one-way trusts among multiple forests or trees can be complicated, so it’s important to keep it simple by limiting the domains that trust one another. Determining the Number of Trees A tree is simply a grouping of domains. The domains that form a tree are arranged hierarchical and share a common and contiguous namespace. Trees can be viewed one of two ways. The first view is the trust relationships among domains. The second view is a view of the namespace of the domain trees as shown in Figure 2.3. In a single forest in which all domains trust one another, the tree relationship is defined by the namespace that is necessary to support the domain structure. For example, the root domain called company.com can have two subdomains (or child domains) named seattle.company.com and chicago.company.com. The relationship between the root domain and the two child domains is what forms the tree, or namespace. In the previous section, I emphasized that multiple forests in an organization are generally not recommended. However, this isn’t to say that there aren’t situations in which multiple trees are appropriate or even recommended. For one, multiple trees allow you to have multiple namespaces that coexist in a single directory. Multiple trees give you additional levels of separation of the namespaces, something that domains don’t provide. Although multiple trees work well in most situations, I recommend that you start by creating one tree until the circumstances arise that call for more. You may be wondering if there are any extraordinary benefits to having multiple trees. For example, do multiple trees reduce the replication or synchronization that occurs among domain servers? The answer is no because the schema and configuration container are replicated to all domain controllers in the forest. In addition, the domain partitions are only replicated among the domain controllers that are in the domain. Having multiple trees doesn’t reduce replication. Likewise, you may be wondering whether multiple trees cause any problems. For example, does having multiple trees require you to establish and maintain explicit one-way trust relationships? Again, the answer is no because the transitive trust relationships are automatically set up among all domains in the forest. This includes all domains that are in separate trees but in the same forest.

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

Chapter 2

31

www.netpro.com

Figure 2.4: The domain structure is a piece of AD. It contains the users, groups, computers, printers, servers, and other resources.

The purpose of domains is to logically partition the AD database. Most large implementations of AD need to divide the database into smaller pieces. Domains enable you to partition AD into smaller, more manageable units that you can distribute across the network servers. Domains are the basic building blocks of AD and Windows 2000. Domains can be connected to form the trees and forests, and what connects them are the trust relationships, which are automatically established in AD. These trusts allow the users of one domain to access the information contained in the other domains. When multiple domains are connected by trust relationships and share a common schema, you have a domain tree. Every AD installation consists of at least one domain tree. It’s your role as an administrator to decide the structure of domains and which objects, attributes, groups, and computers are created. The design of a domain includes DNS naming, security policies, administrative rights, and how replication is handled. When you design domains, follow these steps: • Determine the number of domains • Choose a forest root domain • Assign a DNS name to each domain • Partition the forest • Place the domain controllers for fault tolerance and high network availability • Determine the explicit trust relationships that need to be established, if any.

Chapter 2

32

www.netpro.com

Determining the Number of Domains I recommend that you start with one domain in your environment. This is true even if there are two or more physical locations. This design keeps the layout of your domain simple and easy to maintain. You can then add other domains as needed. The mistake some people make is to create a bunch of domains and not know what to do with them. One domain will be adequate for most companies, especially smaller ones. Although one domain will work in most circumstances, other circumstances necessitate having more than one domain for an entire organization. Some of these are described below; you must decide which of these fit your needs. Administrative Rights

If your organization has multiple administrative groups that want guaranteed autonomy, you may need to create additional domains and give each group its individual rights. For example, if two companies merge together, one group may need to operate and maintain autonomous activities. International Setting

If your organization is international, you may need to create additional domains to support another languages. (Administrators, users, and others may need to access AD in their first language, and the schema contains language-specific attribute display names.) Replication Traffic

Because the AD database can be distributed, you may want to create additional domains to hold the distributed partitions. The need to create additional domains typically arises when you have a single domain trying to replicate across wide area network (WAN) links. If the replication is too slow, you can alleviate the problem by splitting the domain into two. You can then place the two domains on each side of the WAN so that they can be closest to the users. Account Security Settings

Account security settings apply to the entire domain. Account security settings include password length and expiration period, account lockup and intruder detection, and Kerberos ticket policy. These settings cannot be changed in the domain for individual OUs or groups. If you need to have unique settings, you may need to create another domain. Preserve Existing Windows NT Domain

If your company already has an existing Windows NT domain, you may want to keep it instead of consoli dating it into an AD domain. This requirement could produce more domains than planned.

Determining the number of domains for your organization is an individual effort. No one can tell you definitively how many domains to have and how to split them without knowing more about your company’s organization and network. However, using these simple guidelines, you can establish parameters that enable you to effectively design domains and determine the appropriate number for your company.

Chapter 2

33

www.netpro.com

Choosing a Forest Root Domain The first domain that you create becomes the forest root domain (or root domain), which is the top of the forest. The forest root domain is extremely important because it determines the beginning of the namespace and establishes the forest. Because the AD forest is established with the first domain, you need to make sure that the name of the root domain matches the top level in the namespace. For example, root domains are domains with names such as company.com and enterprise.com. These domain names are the roots of the DNS structures and the root of AD. Any subsequent domains you create or add to the tree form the tree hierarchy. The first domain you create in an AD forest contains two forest-wide groups that are important to administering the forest, the Enterprise Administrators group and the Schema Administrators group. Containing these two groups makes the root domain special. You cannot move or re-create these groups in another domain. Likewise, you cannot move, rename, or reinstall the root domain. In addition to these groups, the root domain contains the configuration container, or naming context, which also includes the schema naming context. After you install the root domain, I recommend that you back it up often and do everything you can to protect it. For example, if all the servers holding a copy of the root domain are lost in a catastrophic event and none of them can be restored, the root domain is permanently lost. This is because the permissions in the Enterprise Administrator and Schema Administrator groups are also lost. There is no method for reinstalling or recovering the root domain and its groups in the forest other than completely backing it up and restoring it. Using a Dedicated Root Domain

As I described above, the first domain you create in AD becomes the forest root domain. For smaller implementations of AD, you may only need to create the root domain, nothing more.

For more information on determining the number of domains, see "Determining the Number of Domains" earlier in this chapter.

For a larger implementation with multiple locations around the world, however, you’ll probably want to use a dedicated root domain. A dedicated root domain is a root domain that is kept small, with only a few user account objects. Keeping the root domain small allows you to replicate it to other locations at low cost (that is, with little impact on network usage and bandwidth). Figure 2.5 illustrates how you can replicate a dedicated root domain to the other locations on your network.

Chapter 2

34

www.netpro.com

Figure 2.5: A dedicated root domain is small enough to efficiently replicate copies to the other locations on your network

A dedicated root domain focuses on the overall operations, administration, and management of AD. There are at least two advantages to using a dedicated root domain in a larger implementation of AD. • By keeping the user and printer objects out of the root domain, you enhance security by restricting access to only a few administrators • By keeping the root domain small, you can replicate it to other domain controllers on the network. This approach helps increase the availability of the network.

Because domain administrators can access and change the contents of the Enterprise Administrators and Schema Administrators groups, having a dedicated root domain limits normal access. Membership in these built-in groups should only be given to the enterprise administrators, and they should only access the domain when doing official maintenance. In addition, membership in the Domain Administrators group of the root domain should be granted only to the enterprise administrators. Taking these steps allows you to avoid any accidental changes to the root domain. You should also create a regular user account for each of your administrators so that they don’t carry administrative privileges while doing regular work. As I mentioned earlier in "Choosing a Forest Root Domain," always replicate the root domain to multiple servers in an effort to provide fault tolerance for this domain. Because a dedicated root domain is small (no user or printer objects), it can be replicated across the network more quickly and easily. In addition to replicating the root domain across the local area network (LAN), you can replicate the root domain across the WAN to reduce the trust-traversal traffic among trees.

Chapter 2

35

www.netpro.com

Assigning a DNS Name to Each Domain After you’ve determined the number of domains and installed the root domain, you need to determine the DNS names for each domain. DNS is a globally recognized, industry-standard system for naming computers and network services that are organized in a hierarchy. AD clients make queries to DNS in an attempt to locate and log on to domains and domain controllers. Network users are better at remembering name-based addresses, such as www.company.com, than they are at remembering number-based addresses, such as 124.177.212.34. DNS translates an easy-to-remember name address (www.company.com) into a number address (124.177.212.34). As I’ve mentioned, the domain is identified by a DNS name. You use DNS to locate the physical domain controller that holds the objects and attributes in the domain. DNS names are hierarchical (like AD domains). In fact, the DNS name for a domain indicates the position of the domain in the hierarchy. For example, in the domain name company.com, the DNS name tells us that the domain has to be at the top of the forest and is the root domain. Another example is: marketing.chicago.company.com From this domain name, we know that the domain is the Marketing Department’s domain in the Chicago location of the company. The domain is two levels from the root domain, or top of the tree. The Chicago domain is a child domain of the root domain, or company, and the Marketing domain is a child domain under Chicago. When you create DNS names for the domains in AD, I recommend that you follow these guidelines: • Use an Internet-registered name for the top-level domain • Use Internet standard characters • Use locations to name child domains • Never use the same name twice.

Using an Internet-Registered Name for the Top-Level Domain

When you name your top-level domain, I recommend that you only use a DNS name that has been registered on the Internet and is thus globally unique. For example, realtimepublishers.com is a top-level domain name and should be registered with the Internet Corporation for Assigned Names and Numbers (ICANN). You don’t need to register the names of underlying domains because they fall under the control and jurisdiction of the top-level domain owner/registrant. For example, the domain name research.realtimepublishers.com doesn’t need to be registered. Using Internet Standard Characters

When you assign DNS names, you’re restricted to using only Internet standard characters to ensure compatibility with AD and the Internet. The basic standards for naming are as follows: • Domain names contain only letters, numbers, and hyphens (-) • Domain names cannot begin or end with a hyphen • The domain names of .com, .net, and .org cannot exceed 67 characters Chapter 2

36

www.netpro.com

• Relative domain names (that is, the components between the dots in a fully qualified domain name) can not exceed 22 characters (this doesn’t include any extensions) • Domain names aren’t case sensitive • Domain names cannot include spaces. Using Locations to Name Child Domains

When you determine the name of the child domains, I recommend that you use the geographical locations of your company. This applies to the first layer of child domains that you create under the root domain. The key to designing and naming this layer is the WAN layout: Try to match the domains to the locations in your company’s WAN. For example, the first layer of domains that you create under the root could have names based on physical locations. Figure 2.6 portrays the first layer of domain names, representing the physical, or WAN, locations on your network. I make this recommendation because other naming schemes based on business structures and organizations are prone to constant change. In fact, I guarantee that they’ll change and change many times. The AD domain hierarchy

Figure 2.6: The first layer of domains directly under the root domain is named after the physical, or WAN, locations on the network.

isn’t nearly as fluid or adaptable as the business itself. Once you create and name domains, you cannot move or rename them easily. In addition, you cannot move or rename the root domain. Using locations to name child domains is more flexible because physical locations on a network seldom change. The organization at the specific site may change, but not the physical location itself. This design allows the tree to be more flexible to everyday changes. However, if the physical location is changed or removed, the resources are moved. This includes the physical resources, such as domain controllers, printers, and other equipment supporting the site.

Chapter 2

37

www.netpro.com

If your company is smaller and contained in one physical location, you could name domains after the company or organization. These domains then hold all the objects and attributes for your company. This is an easy and efficient design. However, if your company has multiple physical locations, with network resources spread across them, you’ll want to create a second layer of domains (under the root domain) and give the domains location names. The organizational structures of business units, divisions, and departments will then be placed under each of these location domains. Never Using the Same Name Twice

I recommend that you never use the same DNS name twice, even if the names are used on different networks. This simple guideline will help eliminate any confusion down the road. For example, let’s say you decide to use the domain name engineering.company.com. Don’t use this name for any other domain, even if the domain is on a different network. A client may connect to both networks and query engineering.company.com. Depending on the layout of the network, the client may locate the wrong domain in the wrong forest. Dividing the Forest In larger organizations, the implementation of AD can become quite large. As it grows, I recommend that you break it into smaller pieces, known as partitions. By definition, a partition is a domain or portion of the directory tree that extends from the beginning of a branch (or naming context) to the bottom of the tree. The domain physically stores the containers, objects, and attributes in that branch. Several rules control creating partitions in AD and how they operate. • The topmost partition is the root domain • Partitions don’t overlap (one object cannot be held in two partitions) • The partitions contain all the information for the naming context. In AD, the basic unit of partitioning is the domain. So when you create your first partition, you’re actually creating a child domain under the root domain. The domains in AD act as partitions in the database. This means that each domain represents a partition in the overall AD database. Partitioning this database increases its scalability. As you partition AD, you break it into smaller, more manageable pieces that can be distributed across the domain controllers, or network servers. Figure 2.7 illustrates how you can divide the AD database into smaller pieces that can be distributed to the domain controllers.

Chapter 2

38

www.netpro.com

Figure 2.7: You can partition the AD database into smaller pieces, then distribute them among network servers or domain controllers.

Breaking AD into smaller pieces and distributing them among multiple servers places a smaller load and less overhead on any one server. This approach also allows you to control the amount and path of traffic generated to replicate changes among servers. Once you create a partition, replication occurs among servers that hold copies. In AD, you can create many partitions at multiple levels in the forest. In addition, copies of the domain can be distributed to many different servers on the network. Although AD is distributed using partitions, any user can access the information completely transparently. Users can access the entire AD database regardless of which server holds which data. Of course, users must have been granted the proper permissions. Although a single domain controller may not contain the entire AD database, users can still receive whatever information they request. AD queries the global catalog on behalf of a user to identify the requested object, then resolves the name to a server (domain controller) address using DNS. Again, this process is entirely transparent to the user. Placing the Domain Controllers for Fault Tolerance After you’ve partitioned AD, you need to decide how to distribute each new domain or partition across the network servers. The domain controllers are the servers that store the domains and their distributed copies. One domain controller holds only one copy of an AD partition or domain unless it’s a global catalog. The domain controller stores the objects for the domain or partition to which it belongs. The availability of domain information is strictly determined by the availability of the domain controllers. It’s obvious that the domain controllers must be available so that users can log on and access AD information. For this purpose, never have only one domain controller for any domain. I recommend that you have at least two domain controllers for each domain to provide redundancy and fault tolerance for every domain in your organization.

Chapter 2

39

www.netpro.com

Determining Trust Relationships Trust relationships are logical connections that combine two or more domains into one administrative unit. Trust relationships allow permissions to be associated and passed from one domain to another. Without some sort of trust among domains, users cannot communicate or share resources. In this section, I’ll describe the advantages of using bi-directional trusts, one-way trusts, and cross-link trusts. Using Bi-directional Transitive Trusts

In AD, trust relationships are automatically established between every domain and its parent domain in the tree or forest. This greatly reduces the overhead of managing trust relationships. The types of trusts that are created are new in Win2K and are called bi-directional transitive trusts. The best way to understand the concept of transitive trusts is to use an example. Figure 2.8 shows bi-directional trusts being established among all the domains and their child domains.

Figure 2.8: Each domain has a bi-directional transitive trust relationship between itself and each of its child domains.

One of the advantages of these new trusts is that they’re automatically established among all domains; this allows each domain to trust all the other domains in the forest. Another advantage is that these bi-directional trusts, which are automatically established using Win2K’s Kerberos security mechanism, are much easier to set up and administer than Windows NT–style trusts. Having bi-directional trusts also reduces the total number of trust relationships needed in a tree or forest. For example, if you tried to accomplish the same thing in NT, you’d have to create twoways trusts between one domain and every other domain. This would increase the total number of trusts exponentially with the number of domains. If you have experience with Windows NT domains, you may know something of trust relationships. However, the trusts in AD differ from NT trusts because they’re transitive. To help you understand what this means, I’ll provide an example. Win2K transitive trusts work much like a transitive equation in mathematics. A basic mathematical transitive equation reads as follows: A=B, B=C, therefore A=C Chapter 2

40

www.netpro.com

When applying this transitive concept to trust relationships, you get an understanding of how transitive trusts work among domains. For example, if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A trusts Domain C. Figure 2.9 illustrates this idea. Transitive trust relationships have been set up between Domain A and Domain B and between Domain B and Domain C. Thus, Domain A trusts Domain C implicitly.

Figure 2.9: A domain tree viewed in terms of its transitive trust relationships. Because transitive trust relationships have been set up between Domain A and Domain B and between Domain B and Domain C, Domain A trusts Domain C implicitly.

In Windows NT, trusts were non-transitive, so they didn’t allow this implicit trust to exist. For one domain to trust another domain, an explicit trust relationship had to be created between them. When domains are created in an AD forest, bi-directional trust relationships are automatically established. Because the trust is transitive and bi-directional, no additional trust relationships are required. The result is that every domain in the forest trusts every other domain. Transitive trusts greatly reduce your overhead and the need to manually configure the trusts. Because trusts are automatically set up, users have access to all resources in the forest as long as they have the proper permissions. Transitive trusts are a feature of the Kerberos authentication protocol. The protocol is used by AD and provides distributed authentication and authorization. The parent-child relationship among domains is only a naming and trust relationship. This means that the trust honors the authentication of the trusted domain. However, having all administrative rights in a parent domain doesn’t automatically make you an administrator of a child domain. Policies set in a parent don’t automatically apply to child domains because the trust is in place.

Chapter 2

41

www.netpro.com

Using One-Way Trusts

One-way trusts aren’t transitive and are used among domains that aren’t part of the same forest. If you’re familiar with the one-way trusts in Windows NT, the one-way trusts that exist in Win2K are just the same. However, they’re only used in a handful of situations. First, one-way trusts are often used when new trust relationships must be established among domains of different forests. You can use them among domains to isolate permissions. For example, you can use one-way trusts to allow access among forests and among the domains of the same tree. Figure 2.10 shows how you can create a one-way trust between two domains in two different forests. Setting up a one-way trust allows users to access network resources in the direction of the trust. The actual user rights depend on the access control lists (ACLs) governing the domains.

Figure 2.10: A one-way trust is established between a domain in Forest 1 and a domain in Forest 2. The trust allows access to network resources in each domain.

The second use of one-way trusts is to create a relationship from an AD domain to backward-compatible domains, such as Windows NT. Because Windows NT domains cannot naturally participate in AD transitive trusts, you must establish a one-way trust to them. You have to manage one-way trusts manually, so try to limit the number you use. In both these situations, you can create two one-way trusts among the domains. However, two one-way trusts don’t equal a bi-directional transitive trust in AD. Using Cross-Link Trusts

Cross-link trusts are used to increase performance among domains. Cross-link trust relationships help increase the speed at which users authenticate among domains. However, cross-link trusts are only needed between two domains that are both far from the root domain. To completely understand the need for the cross-link trusts, you first need to understand how user authentication works in AD.

Chapter 2

42

www.netpro.com

When a user needs to authenticate to a resource that doesn’t reside on its own domain, the client first has to determine where the resource is and locate it. If the resource isn’t in the local domain, the domain controller will pass back a referral list of other domain controllers that might have the resource. The workstation then contacts the appropriate servers in the referral list to find the resource. This process continues until the requested resource is found. This process is often referred to as chasing referrals and can take time, especially on large or complex AD networks. Walking up and down the domain tree branches lengthens the time it takes to query each domain controller and respond to the user. To speed this process up, you can establish a cross-link, or shortcut, trust relationship between two domains. If you decide to use a cross-link trust, I recommend that you place it between the two domains that are farthest from the root domain. For example, suppose you have a domain tree that has domains 1, 2, 3, 4, and 5 in one branch and domains 1, A, B, C, and D in another branch. Domains 5 and D are located farthest from the root domain. Let’s say that a user in Domain 5 needs to access a resource in Domain D. To accomplish this request, the authentication process must traverse up the first branch and down the second branch while talking to each domain controller. Continuous authentications like this create a significant amount of network traffic. To alleviate this problem, you can establish a cross-link between Domain 5 and Domain D. Figure 2.11 illustrates the layout of the domain tree with the cross-link established between the two domains.

Figure 2.11: The domain tree has two branches, Domains 1, 2, 3, 4, and 5 are one branch, and domains 1, A, B, C, and D are the second branch. The cross-link trust is established between domains 5 and D.

The cross-link that has been established serves as an authentication bridge between the two domains. The result is a better authentication performance between the domains.

Chapter 2

43

www.netpro.com

Designing Organizational Units for Each Domain An OU is a container object that allows you to organize your objects and tie a Group Policy Object (GPO) to it. Using the OU, you can group similar objects into logical structures in a domain. OUs can also be nested to build a hierarchy in a domain. This hierarchy of containers is typically named after divisions, departments, and groups in your company. When you’re designing and creating the hierarchical structure in each domain, it’s important to understand the following characteristics of OUs: OUs can be nested

An OU can contain other OUs, enabling you to build a hierarchy inside each domain. OUs can help delegate administration

You can delegate administrative tasks to subordinate administrators by creating subordinate OUs. Using nested OUs, you can fine-tune the level of control you need. OUs aren’t security principals

You cannot make an OU a member of a group. You cannot grant users permissions to resources because they reside in a particular OU. Because OUs are used to delegate administration, they can specify who manages the resources in the OUs, but they don’t indicate the resources a user can access. OUs can be associated with a GPO

A GPO enables you to define configurations for users and computers in OUs. For example, you can create a desktop policy that every user in the OU will use. OUs don’t need to be viewed by users

It isn’t necessary for you to design OUs with user navigation in mind. Although users can view the OU structure, it isn’t an efficient method for finding resources. The preferred method for users to find resources is by querying the global catalog. Now that you understand a few of the basic characteristics for OUs, you need to consider the following guidelines for designing an efficient and effective OU structure: • Create OUs to delegate administration • Create OUs to reflect your company’s organization • Create OUs for Group Policy • Create OUs to restrict access. Creating OUs to Delegate Administration I’ve mentioned that OUs can be used to create administrative areas in a domain. Using OUs, you can delegate administrative tasks to subordinate administrators. For example, suppose the Engineering Department wants to administer its own objects and resources in the Chicago domain. You can accomplish this by creating the following OU: engineering.chicago.company.com After you’ve created the new OU and placed all the objects and resources in it, you can grant explicit permissions to the administrators of the Engineering Department so that they can control their own objects. Figure 2.12 illustrates how you can create the Engineering OU in the Chicago domain. Chapter 2

44

www.netpro.com

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

Another nice feature that I mentioned earlier (see "Designing Organizational Units for Each Domain") is that OUs can be nested. This enables you to build a hierarchy in each domain. For example, let’s say the Testing Group in the Engineering Department wants full administrative control over all its resources, such as users, printers, and computers. To accommodate this request, you simply create a new OU directly under the Engineering OU in the Chicago domain. The hierarchical structure now looks like the following: testing.engineering.chicago.company.com After you’ve created the new OU and placed the resources, you can give full privileges to the Testing group’s administrator. If an OU is nested, it inherits the properties of the parent OU by default. For example, if the Engineering OU has certain security or Group Policy objects set, they’re passed down to the Testing OU. The Testing OU is considered nested under the Engineering OU. Be careful to limit the number of OU layers you create. Creating too many layers can increase the administrative overhead. Limiting the number of OU layers also increases user logon performance. When a user logs on to AD, the security policies take effect. To find all these policies, the workstation must search all layers of the OU structure. Having fewer OU layers allows the client to complete this search more quickly. Creating OUs to Reflect Your Company’s Organization If you don’t create OUs in your domain, all users, printers, servers, computers, and other resources are displayed in a single list. This type of layout makes it difficult to search for resources. This problem increases as the number of objects in the domain grows.

Chapter 2

45

www.netpro.com

One of the many benefits of creating OUs in a domain is the organization of this flat layout. OUs allow you to create an organization that reflects your company’s divisions, departments, and groups. In fact, you can use your company’s organizational chart or a similar document to help you. Figure 2.13 illustrates how you can create OUs based on an organizational chart.

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

Creating OUs for Group Policy Group Policy enables you to define Win2K desktop configurations for users and computers. Desktop configurations have settings that govern and control the user’s experience at the workstation. GPOs can also be associated with an OU. This association allows all users and computers in the OU and any nested OUs to receive the settings defined in Group Policy. These settings configure a number of items, including installed software, Registry settings, and logon scripts—just to name a few. For more information on Group Policy, I recommend that you check out another free eBook from Realtimepublishers: The Definitive Guide to Windows 2000 Group Policy by Darren Mar-Elia, a link to which can be found at http://www.realtimepublishers.com.

The ability to set Group Policy on OUs allows you to control a large set of users and computers from a central point. If you have a special need for certain users and computers, you can create an OU and establish Group Policy. For example, if the Accounting Department needs specific settings on its desktops, you can create an OU=Accounting and establish the specific policy. Group Policy will then apply to every user and computer in the new OU.

Chapter 2

46

www.netpro.com

As I mentioned above, GPOs can be associated with OUs as well as the domain and site objects in AD. Because GPOs can be associated with each of these objects, you can create implementations using GPOs to generate various combinations. If you aren’t careful, these combinations can become very complicated and cause you headaches. Creating OUs to Restrict Access The quickest and easiest way to restrict total access to network resources is to create a new OU and place the network resources in it. You can then restrict access to the OU, thereby removing access to the network resources. In addition, the objects representing the network resources are no longer visible. Users who don’t have the right to read an object, can normally still see it in AD. This may be a problem if you have highly secure network resources that you don’t want anyone else to see. You can restrict and hide the resources by creating a new OU in the domain and limiting access to only the few who need it.

Designing the Sites for the Forest Sites are locations on the physical network that contain AD servers. A site is stored in AD as an object and is defined as one or more well-connected TCP/IP subnets. By "well-connected," I mean that the network connectivity among the subnets is highly reliable and supports a data-transfer rate of at least 10 megabits per second. Designing sites and site links in AD takes advantage of the physical network layout. (For an explanation of site links, see "Creating Sites and Site Links Based on Network Topology" below.) The basic assumption is that servers and workstations with the same subnet address are connected to the same network segment and have LAN speeds. Defining a site as a set of subnets allows administrators to easily configure AD access and replication topology to take advantage of the physical network. Sites also help you locate network servers so that they’re physically close to the users who depend on them. It’s your role as an administrator to design the site objects and site links for your tree or forest that assure the best network performance. It’s also your job to determine what speed assures this performance and reduces server downtime as a result of network outages. Establish site objects and site links based on network and subnet speed. While many subnets can belong to a single site, a single subnet can’t span multiple physical sites. To help you establish a design for the sites in your forest, you need to consider the following guidelines: • Create sites and site links based on network topology • Use sites to determine the placement of domain controllers • Use sites to determine the placement of global catalog servers. Creating Sites and Site Links Based on Network Topology When you create sites and site links for your tree or forest, use the physical layout of your network, or topology. Before you can properly create sites and site links, you need a solid understanding of what they are.

Chapter 2

47

www.netpro.com

About Sites

Sites are groups of computers (or subnets) that share high-speed-bandwidth connections on one or more TCP/IP subnets. Subnets are groups of local segments on the network that are physically located in the same place. Multiple site objects create a site topology. Figure 2.14 portrays a site with TCP/IP subnets that exist between the servers and workstations. A LAN always connects a site.

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

One domain can span more than one site, and one site can contain multiple domains. However, for design purposes, it’s important to remember that sites define how replication occurs among domain controllers and which domain controller a user’s workstation contacts for initial authentication. Normally, the workstation first tries to contact domain controllers in its site.

About Site Links

Site links are objects that represent the WAN links on your network. They also represent any low-bandwidth connections between two locations. Site links connect two or more sites together. They help you determine the replication schedule and latency, and they help you determine where to place network servers. The rule is to create a site link when a connection is slower than LAN-speed connection. Defining site links allows administrators to configure AD and replication to take advantage of the network.

Chapter 2

48

www.netpro.com

The site link object has four settings. Cost

Helps the replication process determine the path of the communication among domain controllers Replication Schedule

Determines what time of day the replication process can execute Replication Interval

Helps the replication process determine how often to poll the domain controllers on the other side of the link Transport

Helps the replication process determine which transport protocol to use during communications. Site and site link objects are stored in a special container called the configuration container. The configuration container is stored and replicated to every AD domain controller, providing each server with complete details of the physical network topology. A change to any of the information in the site or site link objects causes replication to every domain controller in the forest. Creating the Site Topology

Sites and site links create the site topology, as shown in Figure 2.15. The site topology helps the replication process determine the path, cost, and protocol among domain controllers.

Figure 2.15: The site topology is created from the site objects and the site links. The site topology helps the replication process determine the path, cost, and protocol among domain controllers.

When you create the site topology, it’s useful to have a complete set of physical LAN and WAN maps. If your company has campus networks at one or more locations, you’ll need to have the physical maps of those locations. These maps should include all the physical connections, media or frame types, protocols, and speed of connections.

Chapter 2

49

www.netpro.com

When defining the sites, begin by creating a site for every LAN or set of LANs that are connected by high-speed bandwidth connections. If there are multiple physical locations, create a site for each location that has a LAN subnet. For each site that you create, keep track of the IP subnets and addresses that comprise the site. You’ll need this information when you add the site information to AD.

Site names are registered in DNS by the domain locator, so they must be legal DNS names. You must also use Internet standard characters—letters, numbers, and hyphens. (For more information, see "Using Internet Standard Characters" earlier in this chapter.)

After you’ve created the sites, you need to connect them with site links to truly reflect the physical connectivity of your network. To do this, you need to first assign each site link a name. Site links are transitive, just like trust relationships in Win2K. This means that if Site A is connected to Site B and Site B is connected to Site C, it’s assumed that Site A can communicate with Site C. The process of generating this site topology is automatic, and it’s handled by a special Win2K service called the Knowledge Consistency Checker (KCC). If you don’t like the topology that the KCC generates for you, you can create it manually. The purpose of creating the site topology is to ensure rapid data communications among AD servers. The site topology is used primarily when setting up replication of AD. However, the placement of the domain controllers and partitions govern when and how replication takes place. Using Sites to Determine the Placement of Domain Controllers After you’ve properly created site and site link objects, you can use them to help you decide how to properly distribute AD partitions across the network servers. Network servers are the domain controllers that store AD domains and their copies. One domain controller holds only one copy of an AD partition or domain. The server works to authenticate users and provide responses to queries about the objects and attributes. Your responsibility is to determine where to place the domain controllers on the network to best suit the needs of the users. I recommend that they be located on or near the users’ subnet or site. When a workstation connects to the network, it typically receives a TCP/IP address from DHCP. This TCP/IP address identifies the subnet or site to which the workstation is attached. If the workstation has a statically assigned IP address, it’ll also have statically configured subnet information. In either case, when users log on to the network, their workstations can reach the closest domain controller site by knowing the assigned address and subnet information. Because computers in the same site are physically close to each other in, communication among them is reliable and fast. Workstations can easily determine the local site at logon because they already know what TCP/IP subnet they’re on, and subnets translate directly to AD sites. If no domain controller is available in the local site, user traffic will cross the WAN links and sites to find other servers. To place the domain controller for best overall connectivity, select the site where the largest numbers of users are located. All the users in that site will authenticate to the local domain controller. This approach guarantees that the users will retrieve their object information from the global catalog partition. The location of the server is important because users are required to access a global catalog server when they log on.

Chapter 2

50

www.netpro.com

Using Sites to Determine the Placement of DNS Servers I’ve already mentioned that DNS and AD are inseparably connected. AD uses DNS to locate the domain controllers. The DNS service enables users’ workstations to find the IP addresses of the domain controllers. The DNS server is the authoritative source for the locator records of the domains and domain controllers on the network. To find a particular domain controller, the workstation queries DNS for the appropriate service (SRV) and address (A) resource records. These records from DNS provide the names and IP addresses of the domain controller. The availability of DNS directly affects the availability of AD and its servers. As mentioned, users rely on DNS as a service. To guarantee DNS as a service, I recommend that you place or have available at least one DNS server for every site on your network. This allows all users to access the DNS service locally. You don’t want users to have to query DNS servers that are offsite to locate the domain controllers that are on their own subnet.

The AD domain controllers query DNS to find each other during replication. A new domain controller participates in replication by registering its locator records with DNS. Likewise, each domain controller must be able to look up these records. This is the case even if the domain controllers are on the same subnet.

If you depend on an outside DNS service, you may need to adjust the number of DNS servers and physical placement, if possible. You’ll also need to verify that the outside DNS service supports the required SRV resource record. If it doesn’t, you may need to install and configure your own implementation of Microsoft’s DNS to support AD. If you don’t want to depend on an existing DNS service or a DNS service that is offsite, you may want to install the Microsoft DNS service that is integrated into AD. The Microsoft DNS service stores the locator records for the domain and domain controllers in AD. You can then have one or more domain controllers provide the DNS service. Again, I recommend that you place at least one DNS server for each site object in your environment. Using the Microsoft DNS service is an optional configuration, and storing the locator records in AD may have a negative impact on replication traffic on large networks.

Summary My first recommendation for troubleshooting AD was to make sure that its components are designed and implemented correctly. In addition, the efficiency of AD depends on the design and implementation of key structures — forests, trees, domains, and OUs. I also recommended that the sites and site links be properly established to support the distribution and replication of the system. I also discussed the placement of other supporting servers, such as domain controllers, global catalog servers, and DNS servers. The design and implementation of these structures is strictly your responsibility as network administrators. Before you can effectively troubleshoot AD, make sure you feel confident about your design.

eBook Copyright Notice This site contains materials created, developed, or commissioned by Realtimepublishers.com, Inc. and is protected by international copyright and trademark laws. No material (including but not limited to the text, images, audio, and/or video) may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at [email protected]

Chapter 2

51

www.netpro.com

Chapter 3

The Definitive Guide to Active Directory Troubleshooting

Monitoring and Tuning the Windows 2000 System and Network A Windows 2000 (Win2K) network is a system of devices that work together toward a common goal of providing communication among users, servers, and applications. The most important of these devices are Win2K domain controllers. This book is primarily interested in the components or software that are required for Win2K Active Directory (AD) services. In this chapter, I’ll focus on how you can monitor Win2K domain controllers and their subsystems to help you reduce downtime and improve AD performance.

Monitoring Windows 2000 Domain Controllers As previously mentioned, domain controllers are the single most important type of device on an AD-based Win2K network. These devices share the responsibility of storing the directory information, and they interact with each other to replicate the directory information and keep it up to date. In addition, domain controllers are responsible for authenticating user logons and servicing other requests for access to directory and network resources. Because domain controllers are crucial to the performance and operation of the directory, it’s critical that you continually monitor these servers. A poorly performing or misbehaving domain controller can easily cause network downtime and loss of directory functionality. For example, when the directory slows down significantly or is unavailable, users can’t log on, there is no Address Book for Exchange, and users can’t print or access Web-based applications. When you consider how you’ll monitor your domain controllers, first remember that no one domain controller contains all of the directory information. In any well-built Win2K network, each domain partition in the directory typically has two or more domain controllers hosting the domain to provide fault tolerance for directory services. With this kind of redundancy in place, you might initially be fooled into thinking that monitoring each domain controller for performance and downtime isn’t all that important. However, each domain controller plays a role in supporting your users. For example, if two domain controllers in the same directory partition are placed in separated sites or subnets, users in each site will use the domain controller nearest them. However, if one of the domain controllers goes down, users in that location must traverse the wide area network (WAN) to log on and access the directory. This is usually undesirable, especially if there are too many users and/or if the WAN link is slow. Another example of why you need to monitor domain controllers is that some domain controllers on a Win2K network (no matter how many domain controllers it may have) are unique. For example, some Win2K domain controllers perform special duties called Flexible Single-Master Operation (FSMO) roles. Although the replication of AD is multimaster, the FSMO roles held by these domain controllers are single-master (much like a Windows NT 4.0 primary domain controller, or PDC). This essentially means that these domain controllers don’t have additional copies or replicas to provide fault tolerance if the domain controller hosting a particular role is down. As I discussed in Chapter 1, these FSMO domain controllers perform special roles for AD, such as managing the domain, managing the schema, and supporting down-level clients. If any of these critical domain controllers go down, the directory loses functionality and can no longer update or extend the schema, or add or remove a domain from the directory.

Chapter 3

53

www.netpro.com

Failing to monitor domain controllers can adversely affect a network’s performance and availability. For example, if an entire department is unable to access the domain controller or directory, users lose time, and the company loses money. To help you ensure that your domain controllers are available, you can, and should, monitor and analyze Win2K in the five following areas: • • • • •

Overall system Memory and cache Processor and thread Disk Network.

I’ll discuss each of these areas, and the reason for their importance, in the following sections. I’ll discuss monitoring AD itself in Chapter 4.

Monitoring the Overall System Monitoring a Win2K domain controller means watching the operation of both the server’s operating system (OS) and its hardware subsystems. When you monitor domain controllers, I recommend that you begin by establishing a performance and reliability baseline for each—that is, a nominal and acceptable level of operation under real-world conditions on your network. Establishing a baseline allows you to track the operation of the domain controller over time. If a potential problem or bottleneck occurs, you can recognize it immediately it because you can compare that behavior to the baseline established for that domain controller. Monitoring domain controllers means watching for problems or bottlenecks in the OS and its subsystems. A simple example of a bottleneck occurs when a domain controller’s processor is running at 100 percent usage because one application has tied up the central processing unit (CPU). Almost every NT/Win2K administrator has seen this occur at some point or another. Win2K provides several utilities that can assist you in monitoring your domain controllers and their subsystems. These tools provide features that will help you search for bottlenecks and other problems. They’re described below. Task Manager

Gives you a quick view of which applications and processes are running on the domain controllers. This utility allows you to view a summary of the overall CPU and memory usage for each of these processes and threads. Performance console

Allows you to view the current activity on the domain controller and select the performance information that you want collected and logged. You can customize Win2K’s performance-counter features and architec ture to allow applications to add their own metrics in the form of objects and counters, which you can then monitor using the Performance console. By default, the Performance console has two applications, System Monitor and Performance Logs and Alerts. System Monitor enables you to monitor nearly every aspect of a domain controller’s performance and estab lish a baseline for the performance of your domain controllers. Using System Monitor, you can see the per formance counters graphically logged and set alerts against them. The alerts will appear in Event Viewer.

Chapter 3

54

www.netpro.com

Performance Logs and Alerts enable you to collect information for those times when you can’t detect a problem in real time. Performance Logs and Alerts allows you to collect domain controller performance data for as long as you want—days, weeks, or even months. Event Viewer

Allows you to view the event logs that gather information about a domain controller and its subsystems. There are three types of logs: the application log, the system log, and the security log. Although the event logs start automatically when you start the domain controller, you must start Event Viewer manually.

When monitoring domain controllers using the Performance console’s logging feature, make sure you don’t actually create a problem by filling the computer’s disk with large log files. First, be sure to only include those statistics in the logging process that you absolutely need. Keep the sampling period to the minimum required to evaluate domain controller performance and usage. To select an appropriate interval for your computer, establish a baseline of performance and usage. Also, take into account the amount of free disk space on your domain controller when you begin the logging process. Finally, make sure that you have some application in place (such as the Performance console) that continually monitors the domain controller to ensure that it has plenty of free disk space. In addition to monitoring the local domain controller, you can use the Performance console to monitor domain controllers remotely and store the log files on a shared network drive. This enables you to monitor all the domain controllers in a directory from one console or utility.

At the heart of the Performance console and Task Manager are the performance counters that are built into the Win2K OS. I’ll introduce each of these monitoring utilities briefly in the upcoming sections and demonstrate how they can help you monitor specific subsystems. Keep in mind that this chapter isn’t intended to be an in-depth study of all the capabilities of these utilities. Instead, my intention is to provide a general introduction to them and show you how you can use them to assist you in monitoring your domain controllers. Using Task Manager The easiest and quickest way to view how each application or system process is using the CPU and memory is by using Win2K’s Task Manager. This utility allows you to see which processes or threads are running on a Win2K domain controller at any given moment; it also shows a summary of overall CPU and memory usage. To launch Task Manager, either right-click the taskbar (typically at the bottom of the screen) and choose Task Manager or press Ctrl+Alt+Del, then click Task List from the menu. Figure 3.1 shows an example of Task Manager.

Chapter 3

55

www.netpro.com

Figure 3.1: Win2K’s Task Manager allows you to view and manage the applications and processes running on a domain controller and manage their performance.

Task Manager supplies three pages of information: Applications, Processes, and Performance. Each of these pages will help you understand more about a domain controller’s processes and memory. I’ll discuss each of these screens in greater detail later in this chapter. Using the Performance Console In Win2K, one of the main utilities for monitoring a domain controller is the Performance console. The Performance console allows you to view the current activity on the domain controller and select the performance information that you want collected and logged. In Windows NT, the Performance console was known as Performance Monitor, and like most NT administration utilities, it was a standalone utility rather than an MMC snap-in.

The Performance console helps you accurately pinpoint many of the performance problems or bottlenecks in your system. It monitors your Win2K domain controller by capturing the selected performance counters that relate to the system hardware and software. The performance counters are programmed by the developer of the related system. The hardware-related counters typically monitor the number of times a device has been accessed. For example, the physical disk counters indicate the number of physical disk reads or writes and how fast they were completed. Software counters monitor activity related to application software running on the domain controller. To launch the Performance console, choose Start>Programs>Administrative Tools>Performance.

Chapter 3

56

www.netpro.com

The first application that starts in the Performance console is System Monitor. Using System Monitor, you can view the current activity on the domain controller and select information to be collected and logged for analysis. You can also measure the performance of your own domain controller as well as that of other domain controllers on your network. System Monitor is shown in Figure 3.2.

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

When it starts up, System Monitor isn’t monitoring any counters or performance indicators for the system. You determine which counters System Monitor tracks and displays. To add a counter, click the Plus (+) tool on the toolbar or right-click anywhere in the System Monitor display area and choose Add Counters from the shortcut menu. Using either approach, the Add Counters dialog box appears, as shown in Figure 3.3, where you can choose which counters to monitor.

Chapter 3

57

www.netpro.com

Figure 3.3: In System Monitor, you can choose which counters you want to track and monitor on the display.

Once you choose the counter that you want to view, System Monitor tracks its performance in real time. When you first start using System Monitor, the number of counters that are available seems overwhelming because there are counters for almost every aspect of the computer. However, in the spirit of the age-old 80/20 rule, you’ll probably find that you tend to use about 20 percent of the available counters 80 percent of the time (or more), using the other counters only when you need specific monitoring or troubleshooting information.

If you don’t understand the meaning of a particular Performance console counter, highlight it and click Explain. The informational dialog box that appears provides a description of the selected counter (and, in some cases, what the various values or ranges might indicate).

In later sections of this chapter, I’ll discuss how you can use System Monitor to monitor memory, view processes, and monitor network components on a domain controller as well as monitor the disk subsystem. Event Viewer As with its NT predecessor, Win2K uses an event logging system to track the activity of each computer and its subsystems. The events that are logged by the system are predetermined and tracked by the OS. In addition, Win2K provides Event Viewer, which allows you to view the events that have been logged. Events Tracked in Event Logs Win2K domain controllers occasionally encounter serious error conditions and halt operation. This situation is called a stop error (also informally known to some users as the "blue screen of death," or BSOD). The error message is displayed on a solid blue background on a domain controller’s console. A number of stop errors are worthwhile monitoring because they affect the reliability of a computer. Fortunately, stop errors are recorded in a domain controller’s Event Log when the computer restarts. To view the stop errors in the Event Log, you need to launch Event Viewer.

Chapter 3

58

www.netpro.com

In addition to stop errors, if a Win2K domain controller restarts, these events are also recorded in the system log section of the Event Log. The reasons for a restart could include OS crashes, OS upgrades, and hardware maintenance. Another type of event that a domain controller tracks in the Event Log is application crashes. Win2K uses the Dr. Watson utility (Drwtsn32.exe) to record problems and failures in applications running on the domain controller. Failures are recorded in the application log section of the Event Log. Again, you can use Event Viewer and the information in the Event Log to analyze problems with an application. Types of Event Logs When you use Event Viewer, the Event Log is separated into three logs, as follows: Application Log

Contains events logged by applications or programs such as Exchange or Microsoft Internet Information Server (IIS) that are running on the computer. The developer of an application decides which events to record. System Log

Contains events logged by the subsystems and components of the domain controller. For example, if a disk driver has problems or fails, it records the events in the system log. You can use this log to determine the general availability and uptime of the domain controller. Security Log

Records security events, such as when a user successfully logs on or attempts to log on. This log also records events that relate to file access. For example, an event is recorded when a file is created, opened, or deleted. By default, the security log can only be seen by system administrators. Starting Event Viewer The event logs start automatically when you start the domain controller; you must start Event Viewer manually. To start or display Event Viewer, choose Start>Run, type eventvwr, then click OK, or choose Start>Programs>Administrative Tools>Event Viewer. Event Viewer starts and displays the following screen (see Figure 3.4).

Chapter 3

59

www.netpro.com

Figure 3.4: The startup screen or display for Event Viewer.

Only a user with administrative privileges can view the security log. Regular users can only view the application and system logs.

Types of Events Logged by Event Viewer Event Viewer logs several types of events, each of which has a different severity to help you analyze a problem. The types of events are as follows: Error

Signifies that a severe problem has occurred. This means that data was lost or functionality was lost. For example, if a service fails to load during startup or stops abruptly, an error is logged. Warning

Less significant than an error and indicates that a problem could occur in the future. For example, a warn ing is logged if disk space becomes too low. Information

Describes important situations that need noting. This event is typically used to notify when an operation is successful—for example, a disk driver loaded successfully and without errors. Success audit

Logs successful access to a secured system resource such as a file or directory object. A success audit event is a successful security-access attempt. For example, if a user attempts to log on to the system and is success ful, a success audit event is logged.

Chapter 3

60

www.netpro.com

Failure audit

Is the opposite of the success audit event. For example, if a user attempts to log on to the system or access a secured resource and fails, a failure audit is logged. Sorting and Filtering Events Using Event Viewer, you can sort events on the screen so that you can easily review and analyze the information. To sort events on the screen, choose View>Newest First (the default) or Oldest First. In addition to selecting the sort order for events, you can filter them. Filtering events allows you to select and view only the events that you want to analyze. To set a filter for events in Event Viewer, choose View>Filter Events. Figure 3.5 illustrates the dialog box that appears to help you specify the filter characteristics.

Figure 3.5: Events can be filtered in Event Viewer to restrict the list of events that are displayed.

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

Chapter 3

61

www.netpro.com

Figure 3.6: The events in Event Viewer can be exported for use with various applications.

Monitoring Memory and Cache One of the most common performance problems with Win2K domain controllers (and all servers, for that matter) is excessive paging, which is caused by insufficient random access memory (RAM). In this situation, one of the greatest performance gains you can achieve is adding more physical RAM to a system. Therefore, I recommend that the first subsystem you monitor be the domain controller’s memory and cache. Problems caused by lack of memory can often appear to be problems in other parts of the system. For instance, a lack of memory can cause insufficient file system cache, which can lead to and be seen as a performance problem in the disk subsystem. Before I give you the details of monitoring your domain controller’s memory, I’ll first briefly introduce the memory model for Win2K. Memory in Win2K provides a page-based virtual memory management scheme (called Virtual Memory Manager, or VMM) that allows applications to address 4 gigabytes (GB) of memory. Memory in Win2K is able to do exactly that by implementing virtual addresses. Each application is able to reference a physical chunk of memory, at a specific virtual address, throughout its life. VMM takes care of whether the memory should be moved to a new location or swapped to disk completely independently of the application. Because everything in the system is realized using pages of physical memory, it’s easy to see that pages of memory become scarce rather quickly. VMM uses the hard disk to store unneeded pages of memory in one or more files called paging files. Paging files represent pages of data that aren’t currently being used but may be needed spontaneously at any time. By swapping pages to and from paging files, VMM is able to make pages of memory available to applications on demand and provide much more virtual memory than the available physical memory. One of the first monitoring or troubleshooting tasks you’ll carry out is to verify that your domain controller has enough physical memory. Table 3.1 shows the minimum memory requirements for a Win2K domain controller. This

Requires this amount of memory

Minimum Installation

64 MB

Server running a basic set of services

128 MB

Server running an expanded set of services

512 MB

Table 3.1: Minimum memory requirements for a Win2K domain controller.

Chapter 3

62

www.netpro.com

These recommendations are minimum physical memory requirements. Your physical memory requirements for actual production servers will typically be much higher. Because your Win2K domain controllers will at least be running AD, I recommend that you always start with at least 512 megabytes (MB) RAM. If you want to load other applications that come with their own memory requirements, you’ll need to add memory to support them. If there isn’t enough memory on your domain controller, it will start running slower as it pages information to and from its hard drive. When physical memory becomes full and an application needs access to information not currently in memory, VMM moves some pages from physical memory to a storage area on the hard drive called a paging file. As the domain controller pages information to and from the paging file, the application must wait. The wait occurs because the hard drive is significantly slower than physical RAM. This paging also slows down other system activities such as CPU and disk operations. As I mentioned earlier, problems caused by lack of memory often appear to be problems in other parts of the system. To maximize the performance and availability of your domain controller servers, it’s important for you to understand and try to reduce or eliminate wherever possible the performance overhead associated with paging operations. Fortunately, there are a couple of utilities that you can use to track memory usage. Two of the most common are utilities I’ve already introduced: Task Manager and the Performance console. Using Task Manager to View Memory on a Domain Controller You can use Task Manager to view memory usage on a domain controller. To do so, click the Performance tab. Figure 3.7 shows an example of the Performance page in Task Manager running on Win2K.

Chapter 3

63

www.netpro.com

Figure 3.7: The Performance page of Win2K’s Task Manager allows you to view a domain controller’s memory usage.

The Performance page in Task Manager contains eight informational panes. The first two are CPU Usage and CPU Usage History. These two panes and the Totals pane all deal with usage on the CPU, or processor. The remaining panes can be used to analyze the memory usage for the domain controller and include the following: MEM Usage

A bar graph that shows the amount of virtual memory your domain controller is currently using. This pane is one of the most useful because it can indicate when VMM is paging memory too often and thrashing. Thrashing occurs when the OS spends more time managing virtual memory than it does executing applica tion code. If this situation arises, you need to increase the amount of memory on the system to improve performance. Memory Usage History

A line graph that tracks the size of virtual memory over time. The history for this pane is only displayed in the line graph and not recorded anywhere. You can use this information to help determine if there is a problem with virtual memory over a longer period of time. Physical Memory

Tells you the total amount of RAM in kilobytes (K) that has been installed on your domain controller. This pane also shows the amount of memory that is available for processes and the amount of memory used for system cache. The amount of available memory will never go to zero because the OS will swap data to the hard drive as the memory fills up. The system cache is the amount of memory used for file cache on the domain controller.

Chapter 3

64

www.netpro.com

Commit Charge

Shows three numbers, which all deal with virtual memory on the domain controller: Total, Limit, and Peak. The numbers are shown in kilobytes K. Total shows the current amount of virtual memory in use. (You’ll notice that this number matches the number shown in MEM Usage.) Limit is the maximum possi ble size of virtual memory. (This is also referred to as the paging limit.) Peak is the highest amount of memory that has been used since the domain controller was started. Kernel Memory

Shows you the total amount of paged and non-paged memory, in kilobytes, used by the kernel of the OS. The kernel provides core OS services such as memory management and task scheduling. I mentioned that you can easily and quickly check the memory usage on your domain controller using Task Manager. Task Manager allows you to see the amount of virtual memory in use. Using the Performance Console to Monitor Memory on a Domain Controller In addition to using Task Manager, you can use the Performance console to determine whether the current amount of memory on a domain controller is sufficient. The System Monitor application in the Performance console allows you to graphically display memory counters over time. I also recommend that you display the memory cache counters. Available Memory Counters To determine if there is a bottleneck in memory, you need to check three memory counters: • Available Bytes (under the Memory object in System Monitor) • Available Kbytes (kilobytes or KB) • Available Mbytes (megabytes or MB). You can use any of these three counters to understand your domain controller’s memory commitment. I recommend that you reserve at least 20 percent of available memory for peak use. To view one or all of the available memory counters, either click the Plus (+) tool on the toolbar or right-click anywhere in the display area and choose Add Counters from the shortcut menu. Once the Add Counters dialog box appears, choose Performance Object>Memory, then choose one of the available memory counters. Figure 3.8 shows the Available Bytes counter of the memory Performance Object.

Chapter 3

65

www.netpro.com

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

The Available Bytes counter shows the amount of physical memory available to processes running on the domain controller. This counter displays the last observed value only; it isn’t an average. It’s calculated by summing space on three memory lists. Free

Memory that is ready or available for use. Zeroed

Pages of memory filled with zeros to prevent later processes from seeing data used by a previous process. Standby

Memory removed from the working set of a process and en route to disk, but still available to be recalled. If Available Bytes is constantly decreasing over a period of time and no new applications are loaded, it indicates that the amount of working memory is growing, or it could signal a memory leak in one or more of the running applications. A memory leak is a situation where applications or processes consume memory but don’t release it properly. To determine the culprit, monitor each application or process individually to see if the amount of memory it uses constantly increases. Whichever application or process constantly increases memory without decreasing it is probably the culprit. Page-Fault Counters When a process or thread requests data on a page in memory that is no longer there, a domain controller issues a page fault. Here, the page has typically been moved out of memory to provide memory for other processes. If the requested page is in another part of memory, the page fault is a soft page fault. However, if the page has to be retrieved from disk, a hard page fault has occurred. Most domain controllers can handle large numbers of soft page faults, but hard page faults can cause significant delays. Chapter 3

66

www.netpro.com

Page-fault counters help you determine the impact of virtual memory and page faults on a domain controller. These counters can be important performance indicators because they measure how VMM handles memory. Page Faults/sec

Indicates the number of page faults without making a distinction between soft page faults and hard page faults. Page Reads/sec

Indicates the number of times the disk was read to resolve hard page faults. This counter indicates the impact of hard page faults. Pages Input/sec

Indicates the number of pages read from disk to resolve hard page faults. This counter also indicates the impact of hard page faults. Figure 3.9 illustrates how you can use System Monitor to track page-fault counters.

Figure 3.9: The Page Faults/sec, Page Reads/sec, and Pages Input/sec counters determine the impact of virtual memory and paging.

If the numbers recorded by these counters are low, your domain controller is responding quickly to memory requests. However, if the numbers are high and remain consistently high, it’s time to add more RAM to the domain controller.

Chapter 3

67

www.netpro.com

Paging File Usage Another important set of counters helps you determine the size of virtual memory. These counters are related to paging file usage. Before I discuss how you can effectively use these counters, it’s important that you better understand the paging file and its function. The paging file is the space on a domain controller that enables the OS to swap out memory to the hard drive. As the domain controller loads more applications than it can run in actual memory, it pages some memory to the hard drive to create room for the new applications. You can see how much the paging file is being used by watching two counters under the Paging File object. % Usage

Indicates the current usage value that was last recorded. % Usage Peak

Indicates the high-water mark for the paging file. If a domain controller was perfect, the OS would have enough memory for every application that was loaded and would never page memory out. Both the % Usage counter and the % Usage Peak counter would be at zero. The opposite is that the domain controller is paging memory as fast as possible, and the usage counters are high. An example of a bad situation is one in which your domain controller has 128MB of memory, the % Usage Peak counter is at 80 percent, and the % Usage counter is above 70 percent. In this situation, it’s fairly certain that your domain controller will be performing poorly. By default, Win2K automatically creates a paging file on the system drive during installation. Win2K bases the size of the paging file on the amount of physical memory present on the domain controller (in most cases, it’s between 768MB and 1536MB). In addition to this paging file, I recommend that you create a paging file on each logical drive in the domain controller. In fact, I recommend that you stripe the paging file across multiple physical hard drives, if possible. Striping the paging file improves performance of both the file and virtual memory because simultaneous disk access can occur on multiple drives simultaneously.

The recommendation for using disk striping on the paging file works best with Small Computer System Interface (SCSI) drives rather than those based on Integrated Device Electronics (IDE) interfaces. This is because SCSI handles multiple device contention more efficiently than IDE and tends to use less CPU power in the process. Also, I don’t recommend that you spread the paging file across multiple logical drive volumes (partitions) located on the same physical drive. This won’t generally aid paging file performance—and it may actually hinder it.

To change or set the virtual memory setting on your domain controller, right-click My Computer, then choose Properties from the shortcut menu. In the System Properties dialog box, click the Advanced tab, then click Performance Options. Notice that the Performance Options dialog box allows you to see the current setting for Virtual Memory. Next, click Change to display more information and to change the paging file settings.

Changing the paging file size or location is unfortunately one of those rare setting changes in Win2K that requires you to restart the domain controller before the change takes effect. So, if you decide to change any settings for the paging file, do it during a scheduled maintenance time when it’s safe to take the domain controller down and doing so won’t affect your users.

Chapter 3

68

www.netpro.com

System Cache In addition to tracking the amount of memory and virtual memory in the domain controller, you need to keep an eye on the computer’s system cache settings. The system cache is an area in memory dedicated to files and applications that have been accessed on the domain controller. The system cache is also used to speed both file system and network input/output (I/O). For example, when a user program requests a page of a file or application, the domain controller first looks to see if it’s in memory (system cache). That’s because a page in cache responds more quickly to user requests. If the requested information isn’t in cache, the OS fulfills the user request by reading the file page from disk. If the system cache isn’t large enough, bottlenecks will occur on your domain controller. The Cache object in System Monitor and its counters help you understand caching in Win2K. In addition, several counters under the Memory object help you determine the amount of file cache. Two of the counters that best illustrate how the file cache is responding to requests are described below. Copy Read Hits %

A counter under the Cache object that tracks the percentage of cache-copy read requests that are satisfied by the cache. The requests don’t require a disk read to give the application access to the page. A copy read is a file-read operation that is satisfied by a memory copy from a page in the cache to the application’s buffer. Cache Faults/sec

A counter under the Memory object that tracks the number of faults that occur when a page sought in the system cache isn’t found. The page must be retrieved from elsewhere in memory (a soft fault) or from the hard drive (a hard fault). When you’re considering using the Copy Read Hits % counter to assess file-cache performance, you might also consider tracking the Copy Reads/sec counter, which measures the total number of Copy Read operations per second. By assessing these numbers together, you’ll have a better sense of the significance of the data provided by the Copy Reads Hits % counter. For example, if it were to spike momentarily without a corresponding jump (or perhaps even a decrease) in the number for overall Copy Reads/sec, the data might not mean much. Ideally, you can identify a cache bottleneck when there is a steady decrease in the Copy Read Hits % counter with a relatively flat Copy Reads/sec figure. A steady increase in both counters, or an increase in Copy Read Hits % and a relatively flat Copy Reads/sec, indicates good file cache performance.

Thus, the Copy Read Hits % counter records the percentage of successful file-system cache hits, and the Cache Faults/sec counter tracks the number of file-system cache misses. Figure 3.10 shows these counters in System Monitor. Remember that one of the counters is a percentage and the other is a raw number, so they won’t exactly mirror each other.

Chapter 3

69

www.netpro.com

Figure 3:10: The Copy Read Hits % and the Cache Faults/sec counters show how the domain controller’s cache is responding.

Generally speaking, I recommend that a domain controller have at least an 80 percent cache hit rate over time. If these two counters show that your domain controller has a low percentage of cache hits and a high number of cache faults (misses), you may want to increase the total amount of RAM. Increasing the RAM allows the domain controller to allocate more memory for system cache and should increase the cache hit rate.

Monitoring Processors and Threads I find that many people mistakenly believe that monitoring a domain controller is focused primarily on the domain controller’s physical processor(s), or CPUs. However, the truth is that the processor doesn’t do anything unless there are processes and threads to run. In Win2K, a process is made up of one or more threads that run on the CPU. A bottleneck at the processor typically means that either one or more processes are consuming most of the processor time or there are too many threads contending for the CPU. A process is an executable program that follows a sequence of steps. Each process requires a cycle from the domain controller’s processor as it runs. A thread is the component of a process that is being executed at any time. Thus, a process must contain at least one thread before it can perform an operation. A single process executing more than one thread is referred to as being multithreaded. Win2K is a multithreaded OS that is capable of running multiple processor threads simultaneously—even, when they’re present, across multiple CPUs.

Chapter 3

70

www.netpro.com

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 priorities to be assigned to each process and thread. The kernel of the Win2K OS controls access to the processor using priority levels. Using Process Viewer to Monitor Processes and Threads Every Win2K domain controller comes with the Process Viewer utility (Pviewer.exe). This utility is part of the Win2K Support Tools, which is located in the Support folder on the Win2K CD. Process Viewer is a great tool for looking at the various processes and associated threads currently running on your domain controller. To launch Process Viewer on your computer, choose Start>Programs>Accessories>Command Prompt, then type pviewer. Figure 3.11 shows an example of Process Viewer.

Figure 3.11: The Process Viewer utility allows you to view the processes and threads running on your domain controller.

Using this utility, you can view the name of each process, the amount of time it’s been running, the memory allocated to it, and its priority. You can also view each thread that makes up a selected process. For each thread, you can see how long it’s been running, its priority, context switches, and starting memory address.

Chapter 3

71

www.netpro.com

In addition to the information you see on the main screen, you can display the memory details for a process. Figure 3.12 illustrates the Memory Details dialog box that is shown when you select a process, then click Memory Details.

Figure 3.12: Memory details for each process are displayed by clicking Memory Details in Process Viewer’s main window.

When using Process Viewer, you can stop or kill a process that is running on a domain controller by selecting it and clicking Kill Process. However, be sure you understand the function and impact of killing a process before doing so—it may be vital to your domain controller’s functionality. Worse yet, by killing a process, you can irrecoverably lose or corrupt the data.

Using Task Manager to View Processes on a Domain Controller Earlier in this chapter (see "Using Task Manager to View Memory on a Domain Controller"), I described using Task Manager as the quickest and easiest method of monitoring the performance of the CPU. You can also use Task Manager to see which processes or threads are running on the Win2K domain controller and to view a summary of overall processor or CPU usage. To launch Task Manager, either right-click the taskbar and choose Task Manager or press Ctrl+Alt+Del, then select Task List from the menu. Then click the Processes tab. A list is displayed of the processes currently running on the domain controller. Figure 3.13 shows an example of the processes running on Win2K and displayed in Task Manager.

Chapter 3

72

www.netpro.com

Figure 3.13: Win2K’s Task Manager allows you to view and manage processes that are currently running on the system.

This view provides a list of the processes that are running—their names, their process identifiers (PIDs), the percentage of CPU processing they’re taking up, the amount of CPU time they’re using, and the amount of memory they’re using. Notice the System Idle Process, which always seems to be toward the top of the process list. This is a special process that runs when the domain controller isn’t doing anything else. You can use the System Idle Process to tell how the CPU isn’t loaded because it’s the exact opposite of the CPU Usage value on the Performance tab. For example, if the CPU Usage value is 5, the System Idle Process value will be 95. A high value for the System Idle Process means that the domain controller isn’t heavily loaded, at least at the moment you checked. Working with the List of Processes You can sort this list of processes according to one of the column labels mentioned above. For example, if you want to view the processes in order of the amount of memory used, simply click that column’s label. The display or list will change accordingly. Task Manager also allows you to customize the columns, thereby receiving additional information about the processes and being able to assess as many as 23 parameters. To customize the columns, on the Processes page, choose View>Select Columns. As shown in Figure 3.14, notice that many additional columns of information can be displayed. These additional columns will help you monitor and tune each process more completely. For more information about each of the additional columns, refer to the Help menu in Task Manager.

Chapter 3

73

www.netpro.com

Figure 3.14: The Select Columns dialog box in Task Manager allows you to monitor additional important statistics about the processes that are running on your domain controller.

In addition, you can see which of these processes belong to an application. To do so, click the Applications tab, right-click one of the applications on the Applications page, then click Go To Process. This will take you to the associated application’s process on the Process tab. This feature helps you associate applications with their processes. As you may know, highlighting a process in Task Manager, then clicking End Process, stops that process from running. This is a useful feature because it allows you to stop processes that don’t provide any other means of being stopped. However, I recommend that you only use this method as a last resort because the process stops immediately and doesn’t have a chance to clean up its resources. Using this method to stop processes may leave domain controller resources unusable until you restart. It may also cause data to be lost or corrupted.

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

Chapter 3

74

www.netpro.com

Figure 3.15: The Computer Management utility allows you to view the processes that are running on your domain controller as well as the path and file name information associated with each process.

Using the Performance Console to View Processes on a Domain Controller You can use the System Monitor application in the Performance console to view the values of the performance counters for the processor, processes, and threads. This utility allows you to graphically display these counters over time. In the next few sections, I’ll discuss some of the counters and how you can use them. % Processor Time Counter The first counter that you should check when monitoring the domain controller is % Processor Time. This counter gauges the activity of the computer’s CPU. It shows the percentage of time that all processors in the domain controller are busy executing code other than the System Idle Process. Acceptable processor activity ranges between 1 percent and 85 percent, although the actual amount depends on the type of applications loaded on your domain controller. The % Processor Time counter is a primary indicator of processor activity. This counter is calculated by measuring the time that the processor spends executing the idle process, then subtracting that value from 100 percent. It can be viewed as the percentage of useful work that the processor executes. To view the % Processor Time counter, you use System Monitor. Figure 3.16 shows the % Processor Time counter in System Monitor.

Chapter 3

75

www.netpro.com

Figure 3.16: The % Processor Time counter give you the ability to view the amount of time that the processor is doing real work.

If the % Processor Time counter is consistently high, there may be a bottleneck on the CPU. I recommend that this counter consistently stay below 85 percent. If it pushes above that, you need to find the process that is using a high percentage of the processor. If there is no obvious CPU "hog," you may want to consider adding another processor to the domain controller or reducing that domain controller’s workload. Reducing the workload might involve stopping services, moving databases, removing directory services, and so on. Interrupts/sec Counter The Interrupts/sec counter measures the rate of service requests from the domain controller’s I/O devices. This counter is the average number of hardware interrupts that the processor is receiving and servicing each second. If this value increases without an associated increase in system response, there could be hardware problems on one of the I/O devices. For example, a network interface card installed in the domain controller could go bad and cause an excessive amount of hardware interrupts. To fix the problem, you need to replace the offending network card’s driver or the physical card. The Interrupts/sec count doesn’t include deferred procedure calls; they’re counted separately. Instead, this counter tracks the activity of hardware devices that generate interrupts, such as the system clock, mouse, keyboard, disk drivers, network interface cards, and other peripheral devices. (For example, the system clock interrupts the CPU every 10 milliseconds.) When an interrupt occurs, it suspends the normal thread execution until the CPU has serviced the interrupt. During normal operation of the domain controller, there will be hundreds or thousands of interrupts per second. System Monitor displays the counter as a percentage of the real number. This means that if the domain controller has 560 interrupts in one second, the value is shown as 5.6 on the graph. Figure 3.17 displays the Interrupts/sec counter using System Monitor.

Chapter 3

76

www.netpro.com

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

In System Monitor, you can make changes to the graph display. To do this, right-click anywhere on the graph, then choose Properties from the shortcut menu. The System Monitor Properties dialog box appears, containing several tabs to change the display and effect of the graph and data. For example, if you want to change the graph scale, click the Graph tab and change the Vertical Scale parameters. To confirm the change, click Apply, then OK.

Unfortunately, it’s difficult to suggest a definite threshold for this counter because this number depends on the particular processor type in use and the exact role and use of the domain controller. I therefore recommend that you establish your own baseline for this counter and use it as a comparison over time. This will help you know when a hardware problem occurs. For example, a network interface card installed in the domain controller could go bad and cause an excessive number of hardware interrupts. By having an established baseline, you can quickly identify that there is a problem. Processor Queue Length Counter The Processor Queue Length counter under the System object displays the number of processes or threads waiting to be executed in the run queue that is shared among all processors on the server. This counter displays the last observed value only; it’s not an average. If there are too many threads waiting for the CPU and the CPU cannot keep up, the system is processor-bound and starts to slow down. Figure 3.18 illustrates how System Monitor shows Processor Queue Length.

Chapter 3

77

www.netpro.com

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

I recommend that your domain controller not have a sustained Processor Queue Length of greater than two threads. If the number of threads goes above two, performance slows down, as does responsiveness to the users. The domain controller shown in the figure could be in trouble, especially if this type of activity is sustained. There are several ways to alleviate the domain controller slowing down. You can replace the CPU with a faster processor, add more processors, and reduce the workload. In some situations, the Processor Queue Length counter will increase if the system is paging heavily, so adding memory or RAM could be needed. To determine if you need more RAM, monitor the paging counters.

Monitoring the Disk Because the hard drives in the domain controller have moving parts, they’re always the slowest subsystem in the computer. In fact, the hard drive subsystem will typically be over 100,000 times slower than the memory subsystem. As a result, the architects of Win2K designed the file-system caching service. Its sole responsibility is to move data off the hard drives and into the faster memory subsystem. This minimizes the performance penalty of retrieving data from the domain controller. By nature, a hard drive is massive and cheap. The disk subsystem can contain hundreds of GB storing millions or billions of files. In turn, memory is relative small and expensive. Therefore, the architects of Win2K designed the virtual memory system to store pieces of memory on the hard drive, thereby allowing more room for users and applications. However, as I discussed earlier (see "Paging File Usage"), you pay a performance price for paging.

Chapter 3

78

www.netpro.com

Using the Performance Console to Monitor the Disk Subsystem Because system performance depends so heavily on the disk subsystem, it’s important that you understand how to monitor it. To properly monitor the disk subsystem, you need to monitor disk usage and response time, which includes the number of actual reads and writes plus the speed with which the disk accomplishes each request. The primary utility you use to monitor these attributes is System Monitor in the Performance console. Using System Monitor, you can view key counters that apply to physical device usage and the logical volumes on the drives. % Disk Time and % Idle Time Counters The % Disk Time counter under the PhysicalDisk object allows you to view how busy the domain controller’s hard drive is. This counter is a percentage of elapsed time that the hard drive is busy servicing read and write requests. The % Idle Time counter under the PhysicalDisk object reports the percentage of time the hard drive is sitting idle. Using these counters, you can monitor the physical activity of the hard drives in each computer. Figure 3.19 illustrates the % Disk Time and % Idle Time counters in System Monitor.

Figure 3.19: The % Disk Time counter allows you to view how busy a physical disk drive is, and the % Idle Time counter tracks the percentage of time a drive is idle.

The figure shows that as you might expect, % Disk Time and % Idle Time basically mirror each other. I recommend that if the value for % Disk Time is consistently above 70 percent, you consider reorganizing the domain controller to reduce the load. However, if the domain controller is a database server, the threshold can go as high as 90 percent. The threshold value depends on the type of server that has been implemented and what has caused the disk I/O. For example, if VMM is paging heavily, it can drive up the % Disk Time counter. The simplest solution here is to add memory.

Chapter 3

79

www.netpro.com

Disk Reads/sec and Disk Writes/sec Counters In addition to the percentage of time the disk is busy, you can also see what the disk is doing. You can monitor this using two counters under the PhysicalDisk object in System Monitor. Disk Reads/sec counter

Tracks the rate of read operations on the disk. Disk Writes/sec counter

Tracks the rate of write operations on the disk. Normally, a domain controller will perform twice as many (if not more) read operations than write operations; it can also service a read request at least twice as fast. This is because the write request has to write the data, then verify that it was written. You can see the Disk Reads/sec and Disk Writes/sec counters in System Monitor, as shown in Figure 3.20.

Figure 3.20: The Disk Reads/sec and the Disk Writes/sec counters show how the domain controller is handling the disk requests that come to it.

Using these counters, watch for spikes in the number of disk reads when your domain controller is busy. If you have the appropriate amount of memory on your domain controller, most read requests will be serviced from the system cache instead of hitting the disk drive and causing disk reads. You want at least an 80 percent cache hit rate; this means that only 20 percent of read requests are forced to the disk. This is valid unless you have an application that reads a lot of varying data at the same time—for example, a database server is by nature disk-intensive and reads varying data. Obtaining a high number of cache hits with a database server may not be possible.

Chapter 3

80

www.netpro.com

Current Disk Queue Length Counter The Current Disk Queue Length counter represents the number of requests outstanding on the disk at any one time. The disk has a queue, or list, that can hold the read and write requests in order until they can be serviced by the physical device. This counter shows the number of requests in service at the time the sample is taken. Most disk devices installed on your domain controller are single-spindle disk drives. However, disk devices with multiple spindles, such as some Redundant Array of Independent Disks (RAID) disk systems, can have multiple reads and writes active at one time. Thus, a multiple-spindle disk drive can handle twice the rate of requests of a normal device. Figure 3.21 displays System Monitor tracking the length of the disk queue.

Figure 3.21: The Current Disk Queue Length counter represents the number of outstanding read and write requests. Using this counter, you can monitor the performance of the queue for the disk drives.

If the disk drive is under a sustained load, this counter will likely be consistently high. In this case, the read and write requests will experience delays proportional to the length of this queue, divided by the number of spindles on the disks. For decent performance, I recommend that the value of the counter average less than 2.

Because gathering disk counters can cause a modest increase in disk-access time, Win2K doesn’t automatically activate all the disk counters when it starts up. By default, the physical disk counters are on, and the logical disk counters are off. The physical disk counters monitor the disk driver and how it relates to the physical device. The logical disk counters monitor the information for the partitions and volumes that have been established on the physical disk drives.

Chapter 3

81

www.netpro.com

To start the domain controller with the logical disk counters on, you use the DISKPERF utility. At the command prompt, type DISKPERF –YV. This sets the domain controller to gather counters for both the logical disk devices and the physical devices the next time the system is started. For more information about using the DISKPERF utility, type DISKPERF /? at the command prompt.

% Free Space Counter An example of a logical disk counter is the % Free Space counter. This counter is the percentage of the free space available on the logical disk or volume. Free space is calculated as a ratio of the total usable space provided on the volume of the logical disk drive. This counter is obviously an important one to monitor because it allows you to view the amount of disk space that is left for user and application requests. This counter allows you to monitor the performance of the disk drives as they start to fill up. This task is important because as a disk drive starts to run out of space, each write request becomes tougher to perform and slows down overall disk performance. The reason for this is that as the drive fills up, each write takes longer to search for space. The longer it takes the disk to write the data, the less it does, so performance slows. Thus, as the drive fills up, it works harder to service requests; this is often called thrashing. I recommend that you always leave at least 10 percent of the disk free to minimize thrashing.

Monitoring the Network Each Win2K domain controller depends on the network to move information to its users and to other servers. However, if the network becomes too crowded and traffic exceeds capacity, performance for all users and domain controllers will suffer. You need to monitor the network components for each domain controller on your network to help eliminate bottlenecks. Monitoring the network typically consists of observing usage on network components and measuring the amount of traffic on the network. Using Network Monitor to Watch Network Traffic Network Monitor (Netmon.exe) allows you to analyze in-depth, low-level network traffic and enables you to detect and analyze problems on your local networks and WAN connections. Network Monitor captures and displays the network packets that the Win2K domain controller receives from users and other servers to provide real-time traffic monitoring and analysis. You can also display the traffic in a post-capture mode to help you analyze it after the fact. In real-time mode, Network Monitor allows you to monitor and test network traffic for a specific set of conditions. If the conditions are detected, it displays the events and prompts you for the appropriate action. In post-capture analysis, network traffic is saved in a proprietary capture file and can be parsed by protocol to pick out specific network frame types. Network Monitor does the following: • Captures network data in real-time or delayed mode • Provides filtering capabilities when capturing network packets • Uses parsers for detailed post-capture analysis.

Chapter 3

82

www.netpro.com

Network Monitor is a complex tool that allows you to monitor all kinds of network traffic and troubleshoot a variety of network problems. Thus, a detailed explanation of it is beyond the scope of this chapter and book.

Using the Performance Console to Monitor Network Components on a Domain Controller You can use System Monitor in the Performance console to monitor the domain controller’s network performance. Specific performance counters allow you to watch the computer’s network throughput and network interfaces. Domain Controller Network Throughput The easiest way to measure domain controller throughput and the bandwidth of each network component is to determine the rate at which the computer sends and receives network data. Several performance counters under the Server object in System Monitor can help you measure the data transmitted through your domain controller’s network components. These counters represent all the network traffic sent to and received from the domain controller and all the network interface cards installed on it. Bytes Total/sec

The number of bytes the domain controller has sent and received from the network each second. This value provides an overall indication of how busy the domain controller is, servicing network requests. It can help you determine whether any network components are creating bottlenecks for network traffic. Bytes Transmitted/sec

The number of bytes that the domain controller has sent on the network. It indicates the network traffic that has been sent. Bytes Received/sec

The number of bytes that the domain controller has received from the network. It indicates the network traffic that has been received. The advantage of the last two counters is that they break out the values for traffic sent and received. I recommend that once you’ve monitored these counters, you compare the results to your domain controller’s total network throughput. To do this, I suggest that you establish a baseline of data rates and averages. Establishing a baseline allows you to know what to expect from the domain controller. If a potential problem or bottleneck in network throughput occurs, you can recognize it immediately because you can compare it against the baseline you’ve established. You can also make some estimates as to where a bottleneck exists if you know the network and bus speeds of the domain controller. If the data rate through the card is approaching the network limit, segmenting and adding a card may help. If the aggregate data rate is approaching the bus speed, it may be time to split the load for the domain controller and add another one or go to clustering. Network Interface Throughput If you want to break down the amount of traffic to each individual network adapter or interface card, you’ll want to use the Network Interface object in System Monitor. The counters that display the amount of traffic processed by each network interface card are Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec. The counters in the

Chapter 3

83

www.netpro.com

previous section have similar names, but they display the amount of traffic for the entire domain controller, regardless of the actual number of interface cards installed. Using the counters assigned to each network adapter allows you to drill down and see how each performs individually. Bytes Total/sec The number of bytes the network interface card has sent and received from the network each second. This value measures the rate at which bytes are both sent and received on the network interface card; this includes all frame and media types. This value also provides an overall indication of how busy the network adapter is. Bytes Sent/sec The rate at which bytes are sent on the network interface. This value breaks down the amount of traffic being sent. Bytes Received/sec The rate at which bytes are received. This value breaks down the amount of traffic being received. Figure 3.22 illustrates how you can use the Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec counters in System Monitor to monitor the domain controller’s network adapter.

Figure 3.22: The Bytes Total/sec, Bytes Sent/sec, and Bytes Received/sec counters allow you to monitor the domain controller’s network adapter.

Chapter 3

84

www.netpro.com

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.

eBook Copyright Notice This site contains materials created, developed, or commissioned by Realtimepublishers.com, Inc. and is protected by international copyright and trademark laws. No material (including but not limited to the text, images, audio, and/or video) may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at [email protected]

Chapter 3

85

www.netpro.com

Chapter 4

The Definitive Guide to Active Directory Troubleshooting

Monitoring Active Directory Troubleshooting Active Directory (AD) and AD-based networks requires that you become familiar with AD constructs as well as monitoring tools and techniques. Monitoring AD allows you to determine whether problems are occurring in any part of the directory. However, it’s sometimes difficult to accurately determine the cause of a problem because AD is distributed across domain controllers and interacts with a number of external services and protocols, such as: • Domain Name System (DNS)—for name resolution • Lightweight Directory Access Protocol (LDAP)—for directory lookups • Transmission Control Protocol/Internet Protocol (TCP/IP)—for transport. AD also has a complex infrastructure containing many different components. To ensure the health of the directory as a system, you must monitor all of these components. You also need to understand AD’s internal processes, such as replication. In this chapter, I’ll describe which infrastructure components you need to continually monitor to ensure AD availability as well as some of the built-in and third-party utilities that are available to help you do so. It’s always a good idea to have a sound understanding of one’s tools before using them, so I’ll start by introducing the tools in our monitoring tool set.

Using the Monitoring Tools You can use several tools to monitor the individual areas of AD and AD as a service or system. These tools include built-in Win2K utilities and Support Tools/Resource Kit utilities as well as those available from third-party independent software vendors (ISVs). This chapter will give you an overview of all of these utilities and describe how they can help you monitor the directory. It won’t give a comprehensive list of all utilities built into Windows 2000 (Win2K) or available on the market, and it won’t provide extensive documentation on any of these tools. Rather, it’ll focus on tools that represent, in my opinion, the best of the built-in and third-party tools. Third-Party Tools In this section, I’ll discuss NetPro’s DirectoryAnalyzer and NetIQ’s AppManager. DirectoryAnalyzer from NetPro

DirectoryAnalyzer from NetPro was one of the first AD monitoring tools on the market, and it performs real-time monitoring and alerting on all aspects of the AD infrastructure. Instead of monitoring individual domain controllers, it monitors the directory as a whole. It does this by monitoring all domain controllers and directory processes at once as a background process. If a problem occurs at any level in the directory, DirectoryAnalyzer alerts, or notifies, your users. If the problem is critical, its integrated knowledge base contains descriptions and troubleshooting methods that will help you solve it. DirectoryAnalyzer monitors the individual structures and components of AD—replication, domains, sites, Global Catalogs (GCs), operations master roles, and DNS (inasmuch as it relates to AD). Each of these components is

Chapter 4

87

www.netpro.com

vital to the operation of AD. DirectoryAnalyzer can monitor and alert on specific conditions and problems in each of the individual structures. The alerts are then recorded at the DirectoryAnalyzer client or console for viewing. Alerts have two levels of severity—warning and critical. Warning alerts indicate that a predetermined threshold has been met in one of the directory structures. Warning alerts help you identify when and where problems may occur. Critical alerts indicate that a predetermined error condition has been met. Critical alerts are problems that need your immediate attention; if you ignore them, AD could lose functionality or the directory altogether. By clicking Current Alerts under View Status in the sidebar, you can display all of the alerts with their associated type, time, and description. Figure 4.1 shows the Current Alerts screen in DirectoryAnalyzer. The alerts have been recorded for the AD domain controllers, directory structures, and directory processes.

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

You can also send alerts to enterprise management systems using Simple Network Management Protocol (SNMP). This allows you to integrate DirectoryAnalyzer alerts with management consoles such as HP OpenView and Tivoli. Alerts can also be recorded in the Event Log of the Win2K system and viewed using the Event Viewer utility. (See "Event Viewer" later in this chapter.) DirectoryAnalyzer logs all alert activity to a history database. You can export the database and analyze alert activity over time using a variety of formats, such as Microsoft Excel, Hypertext Markup Language (HTML), Dynamic HTML (DHTML), and Rich Text Format (RTF). You can also identify trends in the data, finding cycles or periods of high and low alert activity.

Chapter 4

88

www.netpro.com

AppManager from NetIQ

AppManager from NetIQ Corporation is a suite of management products that manages and monitors the performance and availability of Win2K. One of these management products allows you to monitor the performance of AD. For example, AppManager verifies that replication is occurring and up-to-date for the directory by monitoring the highest Update Sequence Number (USN) value for each domain controller. The USN is discussed in more detail later in this chapter (see "Monitoring Replication"). In addition, inbound and outbound replication statistics are tracked, as are failed synchronization requests for the directory. AppManager also allows you to monitor the number of directory authentications per second and monitor the cache hit rate of name resolution. Using this tool, you can monitor and track errors and events for trust relationships. You can also log errors and events to enterprise management systems using SNMP. This means that SNMP traps are generated and routed to a configured network manager. In addition, you can use or run a set of prepackaged management reports that allow you to further analyze current errors and events. You can also set up this utility to send e-mail and pager alerts when an event is detected. Built-In Tools In this section, I’ll discuss System Monitor, Event Viewer, and REPADMIN. System Monitor

For the domain controller in AD, one of the main monitoring utilities is System Monitor. This utility allows you to watch the internal performance counters that relate to the directory on the domain controller. The directory performance counters are software counters that the developers of AD have programmed into the system. Using System Monitor, you can monitor current directory activity for the domain controller. Once you’ve installed AD on a server, several performance counters—for replication activity, DNS, address book, LDAP, authentication, and the database itself—measure the performance of the directory on that computer. I discussed how to launch and use System Monitor in Chapter 3, so I won’t repeat that information here. Instead, I’ll focus on how to use some of the more important performance counters that are available for AD. Remember, System Monitor tracks all of its counters in real time. For this reason, I recommend that you always establish a baseline or normal operation that you can compare the real-time values against. When adding AD counters to System Monitor, if you don’t understand the meaning of any counter, highlight it, then click Explain. The Explain Text dialog box appears and provides a description of the counter. You can also graph the performance counters and set alerts against them. The alerts will appear in the Event Viewer.

Chapter 4

89

www.netpro.com

Event Viewer

To view and analyze the events that have been generated by a Win2K domain controller, you can use the Event Viewer. This utility allows you to monitor the event logs generated by Win2K. By default, there are three event logs: the application log, the system log, and the security log. (These three logs were described in the "Event Viewer" section of Chapter 3.) In addition, after you install AD, three more logs are created. Directory service log

Contains the events that are generated by AD on the domain controller. You can use this log to monitor activity or investigate any directory problems. By default, the directory records all critical error events. DNS server log

Contains the events generated by the DNS service installed on your domain controller. For example, when the DNS service starts or stops, it writes a corresponding event message to this log. More critical DNS events are also logged—for example, if the service starts but cannot locate initializing data, such as zones or other startup information stored in the domain controller’s Registry or AD. The DNS log exists only if the DNS service is running on the server. The DNS service typically runs on only a few domain controllers in the forest. File Replication service log

Contains events generated by file replication on the domain controller. The File Replication service (FRS) is a replication engine used to replicate files among different computers simultaneously. AD uses this service to replicate Group Policy files among domain controllers. Depending on how you configure your AD installation, you may have one or all of these logs on your domain controller. Figure 4.2 shows the Event Viewer startup screen on a domain controller after you’ve installed AD with DNS.

Chapter 4

90

www.netpro.com

Figure 4.2: The Event Viewer startup screen lists additional event logs that have been created for AD.

Replication Diagnostics (REPADMIN)

The Replication Diagnostics tool is simply referred to as REPADMIN. It’s a command-line utility that allows you to monitor and diagnose the replication process and topology in AD. It also provides a number of switches that you can use to monitor specific areas of replication. For example, you can force replication among domain controllers and view the status. During normal replication, the Knowledge Consistency Checker (KCC) manages and builds the replication topology for each naming context on the domain controller. The replication topology is the set of domain controllers that shares replication responsibility for the domain. REPADMIN allows you to view the replication topology as seen by the domain controller. If needed, you can use REPADMIN to manually create the replication topology, although this isn’t usually beneficial or necessary because it’s generated automatically by the KCC. You can also view the domain controller’s replication partners, both inbound and outbound, and some of the internal structures used during replication, such as the metadata and up-to-dateness vectors. You can install the REPADMIN.EXE utility from the 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.

Chapter 4

91

www.netpro.com

Figure 4.3: The REPADMIN utility allows you to view the replication process and topology.

Monitoring the AD Infrastructure An important aspect of any AD deployment is always monitoring the environment and infrastructure. The infrastructure of AD is the set of processes and data structures that the directory service uses to function properly. By constantly monitoring the infrastructure, you can detect issues that arise in the environment and correct them before they affect your users. For example, users will be affected if there is an intermittent failure of a bridgehead server or if a Flexible Single Master Operation (FSMO, pronounced "fizmo") role-holding server goes down. The first task in troubleshooting AD is to constantly monitor critical areas of the directory deployment. I recommend that you continuously monitor at least the following directory structures and components:

Chapter 4

92

www.netpro.com

Domain controllers

These are critical to the proper operation of AD. If one domain controller isn’t functioning properly, the directory and some users will lose performance and possibly functionality. If the domain controller that is having problems has also been assigned additional vital roles (such as being a DNS or GC server), the directory may become unavailable to all users. Thus, it’s critical to monitor and track the performance of all domain controllers on the network at all times. Domain partition

Stores AD objects and attributes that represent users, computers, printers, and applications. The domain partition is also used to accomplish a number of management roles, which include administration and replication. You must monitor the performance and availability of the domain partition so that the services it supports are constantly available. GC partition

Stored on domain controllers throughout the network. Only a few domain controllers store a copy of the GC partition, and they need to be monitored for the GC. GCs are specialized domain controllers whose availability is necessary for clients to be able to log on to the network. The GC streamlines directory searches because it contains all of the objects in the forest but only a few of their key attributes. Operations masters

These (or FSMO role holders) are single-master domain controllers that perform special roles for AD. It’s important that you monitor and track the performance of each operations master so that the service it performs is maintained. If any operations master stops functioning, its functionality is lost in the directory. Replication process and topology

Are critical to the operation of AD. If changes have been made to a directory object on one domain controller, the replication process needs to propagate the changes to all of the other domain controllers that have replicas of that object. If replication isn’t functioning, different portions of the directory get out of sync. This confuses users, and they lose access to directory resources. For example, if an administrator has changed a Group Policy but the change hasn’t been synchronized to all copies, users using the older copies may access the wrong information. In addition, once the synchronization among directory replicas is lost, it’s very difficult and time-consuming to get back. Thus, it’s critical to constantly monitor the replication process and topology for problems.

Monitoring the Domain Controllers Because AD can be distributed across many domain controllers, you need to constantly monitor individual domain controllers. If one domain controller isn’t functioning properly, the directory and your users will lose performance and possibly functionality. If multiple domain controllers aren’t functioning properly, the network can become unusable. For this reason, I recommend that you always check or monitor that the domain controller’s hardware and subsystems are operating correctly. (For details on how to monitor the hardware components of the domain controller, refer to Chapter 3.) After you’re confident that the hardware is performing well, you need to monitor the AD services running on the domain controllers for errors and other problems.

Chapter 4

93

www.netpro.com

Using DirectoryAnalyzer Many third-party tools (such as those I discussed earlier) provide you with an easy way to monitor all of the domain controllers in your forest from one management console. For example, in DirectoryAnalyzer, click Browse Directory By Naming Context; the directory hierarchy is displayed. If you expand the naming contexts, you see all of the associated domain controllers. To see the alerts for just one domain controller, select a domain controller object, then click Current Alerts. The alerts that are displayed have exceeded a warning or critical threshold and show the severity, subject, associated type, time, and description. Figure 4.4 shows an example of using DirectoryAnalyzer to view all alerts for each domain controller.

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

To see the alerts and other information for each domain controller, you can also use the Browse Directory By Site option. It allows you to browse the directory layout according to sites and their associated domain controllers. In addition, it permits you to view the status of each site and the site links.

DirectoryAnalyzer is an extremely useful utility because it monitors all of the domain controllers in the AD forest as a background process and allows you to periodically view the results. It also monitors the most critical directory structures and processes—for example, the configuration and activity for the domain partitions, GC partitions, operations master roles, sites, DNS, the replication process, and the replication topology.

Chapter 4

94

www.netpro.com

In addition to viewing the alerts from the domain controllers, you can click any alert and see a more detailed description of the problem. If you don’t understand the alert, you can double-click it; the Alert Details dialog box will appear and provide more description, as shown in Figure 4.5.

Figure 4.5: DirectoryAnalyzer provides more information about an alert in the Alert Details dialog box.

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

Chapter 4

95

www.netpro.com

Figure 4.6: DirectoryAnalyzer’s in-depth knowledge base helps you find solutions to problems in AD.

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.

Chapter 4

96

www.netpro.com

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

Figure 4.7: You can view detailed information about a domain controller using the DC Information pane in DirectoryAnalyzer.

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

Chapter 4

97

www.netpro.com

Figure 4.8: The DC Summary pane in DirectoryAnalyzer provides a high-level status of all domain controllers in a domain.

You can also quickly view where the domain controller resides, if it’s a GC, and who manages the computer. If any of the domain controllers aren’t showing a green (clear) status icon, there is a problem that you need to investigate and fix. Using NTDS Performance Counters NTDS (NT Directory Service) performance counters are internal domain controller counters used by multiple aspects of AD. Once AD has been installed on the domain controller, these directory counters are added to the system. These counters allow you to monitor and track the domain controller’s replication activity, LDAP traffic, and authentication traffic. Table 4.1 describes the more useful NTDS performance counters and how to use them to track AD activity on a domain controller.

This Counter

Does This

How to Use It

DRA Inbound Bytes Total/sec

Tracks the total number of bytes per second received on the server during replication with other domain controllers.

Indicates the total amount of inbound replication traffic over time. If a small number of bytes are being sent, either the network or the server is slow. Other issues that might limit the number of bytes being sent include few changes being made to the naming contexts hosted by the domain controller, replication topology problems, and connectivity failures. Of course, you need to check this value against a baseline of activity.

Chapter 4

98

www.netpro.com

This Counter

Does This

How to Use It

DRA Inbound Object Updates Remaining in Packets

Tracks the number of object updates received in the AD replication update packet but not applied to the local domain controller.

Indicates that the server is receiving changes but is taking a long time to apply them to the AD database. The value of this counter should be as low as possible. A high value indicates that the network is slow during replication or the domain controller is receiving updates faster than it can apply them. Other issues that can affect speed of update are high domain controller load, insufficient hardware (memory, disk, or CPU), the disk becoming full or fragmented, other applications using too many resources, and so on.

DRA Outbound Bytes Total/sec

Tracks the number of bytes that are sent from the server during replication to other domain controllers.

Indicates the total amount of outbound replication traffic over time. If this value remains low, it can indicate a slow server or network or few updates on this domain controller. In the latter case, it can mean that clients are connecting to other domain controllers because this one is slow or that there are topology problems. For best results, test the current value against an established baseline value.

DRA Pending Replication Synchronizations

Tracks the number of pending requests from replication partners for this domain controller to synchronize with them. Synchronizations are queued, ready for processing by the domain controller.

Indicates the backlog of directory synchronizations for the selected server. This value should be as low as possible. A high value could indicate a slow server or a problem with the server’s hardware.

DS Threads in Use

Tracks the current number of threads that are being used by the directory service running on the domain controller.

Indicates how the directory service on the server is responding to client requests. When a client requests information, AD spawns a thread to handle the request. If the number of threads remains constant, Win2K clients may experience a slow response from the domain controller.

Kerberos Authentications/sec

Tracks the current number of authentications per second for the domain controller.

Indicates how the domain controller is responding to client requests for authentications. If this counter doesn’t show activity over time, clients could be having a problem contacting the domain controller.

LDAP Bind Time

Tracks the amount of time (in milliseconds) required to process the last LDAP bind request from the client. A bind is described as authenticating the LDAP client.

This counter tracks only the last successful bind for an LDAP client. The value of this counter should be as low as possible to indicate that the domain controller was quick to authenticate the LDAP client. If the value is high, the domain controller was slow to authenticate LDAP. A high value can indicate a server problem, the domain controller is too busy, insufficient hardware (memory or CPU), or other applications using too many resources.

Chapter 4

99

www.netpro.com

This Counter

Does This

How to Use It

LDAP Client Sessions

Tracks the current number of LDAP sessions on the selected domain controller.

If your domain controller has LDAP clients trying to connect, the value of this counter should show activity over time. If the value remains constant, the server or client may have problems, the domain controller may be too busy running other applications, or there is insufficient hardware (memory or CPU).

LDAP Searches/sec

Tracks the number of LDAP search operations that were performed on the selected domain controller per second. LDAP clients connecting to the server perform the LDAP search operations.

Indicates how many LDAP search requests the domain controller is servicing per second. You typically view different search rates depending on the domain controller’s hardware, the number of clients connected to the domain controller, and what sorts of things the clients are doing.

LDAP Successful Binds/sec

Tracks the number of LDAP binds per second that occur successfully.

Indicates how the domain controller responds to authentications from the clients. This value allows you to view the number of successful binds per second for LDAP clients. Again, if this value remains constant over time, there can be a network, client, or server problem. For example, there is a bad network component, the client is too busy, or the server is too busy.

NTLM Authentications

Tracks the total number of Windows NT LAN Manager (NTLM) authentications per second serviced by the domain controller.

Allows you to see whether there are authentications from Windows 98 and NT clients for this domain controller. If you’re supporting Windows 98 and NT and the value remains constant over time, there is a network problem. For example, the network could have a bad or poorly configured component, or the client could be too busy.

Table 4.1: A few of the NTDS performance counters that allow you to track how a domain controller is responding to replication traffic, LDAP traffic, and authentication traffic.

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.

Chapter 4

100

www.netpro.com

Figure 4.9: NTDS performance counters allow you to monitor and track load and performance of the AD implementation on each domain controller.

Monitoring the Domain Partitions Domain partitions in AD are often referred to as naming contexts, and they provide a security and replication boundary. Each domain partition exists in the NTDS.DIT database on the domain controllers that participate in the domain. The domain partition stores all the users, printers, servers, computers, and application data. Because users depend on the domain to access other network resources, it’s important that you constantly monitor the state of the domain partition. Using DirectoryAnalyzer 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).

Chapter 4

101

www.netpro.com

Figure 4.10: DirectoryAnalyzer allows you to monitor each domain partition for problems.

In addition to displaying alerts for each domain, DirectoryAnalyzer allows you to view configuration information. Using the Naming Context Information tab, you can view the current number of alerts that are active for the following areas: Naming Context (or Domain), Replica, DNS Server, and DC Server. The Naming Context Information tab also displays the number of domain controllers for the domain and whether the domain supports mixed mode. When a domain supports mixed mode, it allows replication and communication with down-level domain controllers and clients to occur. In addition, you can see which domain controllers in the domain are performing the 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.

Chapter 4

102

www.netpro.com

Figure 4.11: The Naming Context Information pane in DirectoryAnalyzer allows you to see detailed information for a domain.

To further monitor the domain, DirectoryAnalyzer provides a high-level summary of each domain controller. Click Browse Directory By Naming Context, then click the DC Summary tab. (The DC Summary pane is shown in Figure 4.8 earlier in this chapter.) Using Domain Database Performance Counters In AD, the database for the domain has been implemented as an indexed sequential access method (ISAM) record or table manager. This table manager is often referred to as the Extensible Storage Engine (ESE) and is implemented by ESENT.DLL on the server. By default, the associated database file is stored on the Win2K server as \WINNT\NTDS\NTDS.DIT.

If necessary, you can relocate the NTDS.DIT database on a domain controller using the NTDSUTIL utility.

Using this database engine, AD provides a set of database performance counters that allow you to monitor the domain in depth. These counters provide information about the performance of the database cache, database files, and database tables, and they help you monitor and determine the health of the database for the domain controller. By default, database performance counters aren’t installed on the domain controllers. (For instructions on installing them, see "Installing the Counters" below.) You can view and monitor database counters using the System Monitor utility. Table 4.2 gives you a general description of the more useful database performance counters and how to use them to track the activity of the low-level database for each domain.

Chapter 4

103

www.netpro.com

This Counter

Does This

How to Use It

Cache % Hits

Tracks the percentage of database page requests in memory that were successful. A cache hit is a request that is serviced from memory without causing a file-read operation.

Indicates how database requests are performing. The value for this counter should be at least 90%. If it’s lower than 90%, the database requests are slow for the domain controller, and you should consider adding physical memory to create a larger cache.

Cache Page Faults/sec

Tracks the number of requests (per second) that cannot be serviced because no pages are available in cache. If there are no pages, the database cache manager allocates new pages for the database cache.

Indicates how the database cache is performing. I recommend that the computer have enough memory to always cache the entire database. 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.

File Operations Pending

Tracks the number of pending requests issued by the database cache manager to the database file. The value is the number of read and write requests that are waiting to be serviced by the OS.

Indicates how the OS handles the read/write requests to the AD database. I recommend that the value for this counter be as low as possible. If the value is high, you need to add more memory or processing power to the domain controller. This condition can also occur if the disk subsystem is bottlenecked.

File Operations/sec

Tracks the number of requests (per second) issued by the database cache manager to the database file. The value is the read and write requests per second that are serviced by the OS.

Indicates how many file operations have occurred for the AD database. I recommend that this value be appropriate for the purpose of the domain controller. If you think that the number of read and write operations is too high, you need to add memory or processing power to the computer. However, adding memory for the file system cache on the computer reduces file operations.

Table Open Cache Hits/sec

Tracks the number of database tables opened per second. The database tables are opened by the cached schema information.

Indicates how the AD database is performing. The value for this counter should be as high as possible for good performance. If the value is low, you may need to add more memory.

Table 4.2: Some of the more useful database performance counters, which allow you to monitor the database for the domain partition that stores all of the AD objects and attributes.

Chapter 4

104

www.netpro.com

Installing the Counters

By default, database performance counters aren’t installed on the domain controller. To install them, you must use the dynamic-link library (DLL) file called ESENTPRF.DLL. The instructions for installing the counters are as follows: 1. Copy the %System%\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 don’t 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 you’ve installed the database performance counters, you can use them to track and monitor the database on the domain controller. As mentioned earlier in "Using NTDS Performance Counters," you can view and track each counter using the System Monitor utility in the Performance Console.

Monitoring the Global Catalog As I’ve discussed in previous chapters, special servers on Win2K networks store a Global Catalog (GC) partition, which is replicated in AD. The domain controllers that contain the GC partition are referred to as GC servers. Because only the first domain controller installed in a forest is made a GC, you need to determine and specify which subsequent domain controllers will act as GC servers. In addition, you need to constantly monitor the GC partition to ensure that it remains healthy. The GC has been designed to support two crucial functions in an AD forest: user logons and forest-wide queries or searches. It does this by storing all of the objects in the forest and the key attributes for each. It doesn’t store all the attributes for each object; instead, it stores only the attributes it needs to perform queries and support the logon process. One of these attributes is the distinguished name of the object.

Chapter 4

105

www.netpro.com

Once users query and retrieve the distinguished name from the GC, they can issue a search on their local domain controller, and LDAP will chase the referrals to the domain controller that stores the real object information. In addition, universal group membership is stored in the GC. Because universal groups can deny access to resources, a user’s membership in this group must be discovered during logon to build the logon access token. The requests made to the GC are automatic and not seen by the user. You can use DirectoryAnalyzer to monitor the GC partition and how it’s performing. It monitors and tracks the following conditions: Domain Controller: Global Catalog Load Too High

Indicates that the domain controller that stores the GC partition has too much traffic. This is LDAP traffic coming from workstations and servers. Domain Controller: Global Catalog Response Too Slow

Indicates that the domain controller that stores the GC partition isn’t responding in time to queries and other traffic. Replica: GC Replication Latency Too High

Indicates that replication is taking too long to synchronize the GC stored on the domain controller. If replication latency (the time it takes to replicate changes to all GCs in the forest) is too high, an alert is generated. Site: Too Few Global Catalogs in Site

Indicates that there aren’t enough GC servers in the site. Figure 4.12 shows how DirectoryAnalyzer monitors and tracks alerts for the GC.

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

Chapter 4

106

www.netpro.com

Monitoring Operations Masters To prevent conflicting updates in Win2K, AD provides a single-master server to update certain operations. In a single-master model, only one server is allowed to provide updates for the forest or domain. When a domain controller takes on the responsibility of the single-master operation, it’s taking on a role. Thus, this method of updates is called single-master operation roles. When only one domain controller can take on the role at one time, it’s referred to as a Flexible Single Master Operation (FSMO) role. There are currently five types of operations masters in AD. The directory automatically elects the operations master servers during the creation of each AD forest and domain. (For more detail on these FSMOs, see Chapter 1.) Two operations masters manage forest-wide operations, so have forest-specific FSMO roles. Schema master

Responsible for schema extensions and modifications in the forest Domain naming master

Adds and removes domains in the forest. Three operations masters manage domain operations and so have domain-specific FSMO roles. Infrastructure master

Updates group-to-user references in a domain RID master

Assigns unique security IDs in a domain PDC emulator

Provides primary domain controller support for down-level clients in a domain.

The three domain-specific FSMO roles exist in every domain. Thus, an AD forest with a total of 3 domains would have 11 FSMO roles in all: 9 domain-specific roles and 2 forest-wide roles.

Because there is only one of each of the forest-specific FSMO roles, it’s extremely important that you constantly monitor and track the activity and health of the operations masters. If any of them fail, the directory loses functionality until the computer is restarted or another appropriate domain controller is assigned the role. To monitor operations masters, you can use DirectoryAnalyzer. It monitors, checks the status of, and alerts on several types of conditions and situations relating to operations masters, such as which domain controllers are holding the operations masters. Click Browse Directory By Naming Context, and click the Naming Context Information tab. Under Operations Master Status, you see which domain controller is holding which FSMO. Figure 4.13 shows the status of operations masters in the Naming Context Information pane.

Chapter 4

107

www.netpro.com

Figure 4.13: DirectoryAnalyzer displays which domain controllers are holding which operations masters for the naming context.

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.

Chapter 4

108

www.netpro.com

Figure 4.14: DirectoryAnalyzer allows you to monitor and check consistency for each operations master.

In addition to showing the status and consistency checks, DirectoryAnalyzer monitors and displays alerts for each operations master. The alerts that are monitored and tracked provide information about the availability of the FSMOs. To monitor the availability of the operations masters, you can click Current Alerts in the sidebar on the main screen. To display the alerts for a domain or each domain controller, click Browse Directory By Naming Context. The alerts indicate that the domain controller that holds the operations master isn’t responding. This could mean that the domain controller and AD are down and not responding. It could also mean that the domain controller no longer has network connectivity, and this could indicate DNS or Internet Protocol (IP) addressing problems. Finally, this alert could simply mean that the domain controller or the directory that is installed is overloaded and responding too slowly. Figure 4.15 shows how DirectoryAnalyzer monitors and tracks alerts for each operations master.

Chapter 4

109

www.netpro.com

Figure 4.15: DirectoryAnalyzer monitors and tracks the availability of each operations master.

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

Chapter 4

110

www.netpro.com

Using Directory Partition Replicas A directory partition replica can be a full replica or a partial replica. A full replica contains all of the objects and attributes of a partition and is read- and write-accessible. A partial replica contains a subset of the objects and attributes and is read-only. Partial replicas are stored only on a GC server. Each domain controller stores at least three full directory partitions, or naming contexts, which include the schema partition, configuration partition, and domain partition. Schema Partition

The schema partition contains the set of rules that defines the objects and attributes in AD. This set of rules is used during creation and modification of the objects and attributes in the directory. The schema also defines how the objects and attributes can be manipulated and used in the directory. The schema partition is global; this means that every domain controller in the forest has a copy, and these copies need to be kept consistent. To provide this consistency, the replication process in the directory passes updated schema information among the domain controllers to the copies of the schema. For example, if an update is made to the schema on one domain controller, replication propagates the information to the other domain controllers, or copies of the schema. Configuration Partition

The configuration partition contains the objects that define the logical and physical structure of the AD forest. These objects include sites, site links, trust relationships, and domains. Like the schema partition, the configuration partition exists on every domain controller in the forest and must be exactly the same on each one. Because the configuration partition exists on every domain controller, each computer has some knowledge of the physical and logical configuration of the directory. This knowledge allows each domain controller to efficiently support replication. In addition, if a change or update is made to a domain controller and its configuration partition, replication is started, which propagates the change to the other domain controllers in the forest. Domain Partition

The domain partition contains the objects and attributes of the domain itself. This information includes users, groups, printers, servers, organizational units (OUs), and other network resources. The domain partition is copied, or replicated, to all of the domain controllers in the domain. If one domain controller receives an update, it needs to be able to pass the update to other domain controllers holding copies of the domain. A read-only subset of the domain partition is replicated to GC servers in other domains so that other users can access its resources. This allows the GC to know what other objects are available in the forest. Using Directory Updates AD updates are changes made to an object or attribute stored on a domain controller. When an update occurs, the domain controller that receives it uses replication to notify other domain controllers holding replicas of the same partition. The domain controller that receives the update (called the originating domain controller) notifies its replication partners of the change first, then the partners requesting the appropriate changes. A write request from a directory client is called an originating write. When an update that originates on one domain controller is replicated to another domain controller, the update is called a replicated write. Using this approach, AD can distinguish update information during replication.

Chapter 4

111

www.netpro.com

AD replication doesn’t use date or time stamps to determine what changes need to be propagated among domain controllers; instead, it uses Update Sequence Numbers (USNs). A USN is a 64-bit counter that is associated with each object. It increments each time a change is initiated, then it’s associated with the change. To view the USN of an object, use the following command at a command prompt: REPADMIN /showmeta