Active Directory

Operations Guide

Part I: Active Directory Operations

Version 1.5

Developed by the Windows Resource Kits team

Microsoft Windows 2000

Microsoft Corporation

Acknowledgements

Program Managers: Stuart Kwan, Andreas Luther, Chris Macaulay, Paul Reiner

Writers: Mary Hillman, Dave Kreitler, Merrilee McDonald, Randy McLaughlin, Andrea Weiss

Editors: Laura Graham and Justin Hall

Copy Editors: Bonnie Birger, Anika Nelson, Dee Teodoro

Test Plan: Mary Hillman and Cheryl Jenkins

Testers: Justin Hall, David Stern, Matt Winberry

Lab Staff: Robert Thingwold and David Meyer

Lab Partners: Hewlett-Packard and Cisco Systems

We thank the following people for reviewing the guide and providing valuable feedback:

Tadao Arima, Bill Bagley, Colin Brace, Duncan Bryce, J.C. Cannon, Sudarshan Chitre, Arren Conner, Joseph Davies, Jim Dobbin, Levon Esibov, Eric Fitzgerald, David Golds, Jin Huang, Khushru Irani, J.K. Jaganathan, Kamal Janardhan, Asaf Kashi, William Lees, Jonathan Liem, Doug Lindsey, Arun Nanda, Paul O’Connell, Boyd Peterson, Paul Rich, Murli Satagopan, Sanjiv Sharma, Michael Snyder, David Stern, Mark Szalkiewics, Kahren Tevosyan, Derek Vincent

Contents

Contents. 3

Introduction. 7

Using the Microsoft Operations Framework for Active Directory Operations. 7

Audience. 8

Using this Guide. 8

Managing Active Directory. 10

Overview of Active Directory Operations. 11

Planning for Active Directory Operations. 11

Tools Used for Active Directory Operations. 12

Operations Tasks Checklist 15

Monitoring Active Directory. 18

Active Directory Backup and Restore. 24

Backing Up Active Directory and Associated Components. 33

Performing a Non-Authoritative Restore. 33

Performing an Authoritative Restore of a Subtree or Leaf Object 33

Performing an Authoritative Restore of Entire Directory. 34

Recovering a Domain Controller Through Reinstallation. 34

Restoring a Domain Controller Through Reinstallation and
Subsequent Restore from Backup. 35

Managing Domain Controllers. 35

Installing and Removing Active Directory. 36

Preparing for Active Directory Installation. 41

Installing Active Directory. 42

Performing Active Directory Post-Installation Tasks. 44

Decommissioning a Domain Controller 47

Renaming Domain Controllers. 49

Identifying the Current Configuration of a Domain Controller 51

Renaming a Domain Controller 52

Restoring the Original Configuration of a Domain Controller 53

Managing Global Catalog Servers. 54

Identifying Global Catalog Servers in a Site. 56

Identifying a Site That Has No Global Catalog Servers. 57

Adding the Global Catalog to a Domain Controller and
Verifying Readiness. 57

Removing the Global Catalog from a Domain Controller 60

Managing Operations Masters. 60

Designating Operations Master Roles. 68

Reducing the Workload on the PDC Emulator 69

Decommissioning a Role Holder 70

Seizing Operations Master Roles. 71

Choosing a Standby Operations Master 72

Managing the Database. 73

Relocating Directory Database Files. 77

Returning Unused Disk Space from the Directory Database to the
File System... 79

Speeding Removal of an Expired-Tombstone Backlog. 80

Managing SYSVOL. 81

Changing the Space Allocated to the Staging Area. 88

Relocating the Staging Area. 90

Moving SYSVOL by Using the Active Directory Installation Wizard. 90

Moving SYSVOL Manually. 93

Updating the System Volume Path. 95

Restoring and Rebuilding SYSVOL. 95

Managing Windows Time Service. 96

Configuring a Time Source for the Forest 98

Configuring a Reliable Time Source on a Computer Other than the
PDC Emulator 99

Configuring a Client to Request Time from a Specific Time Source. 100

Optimizing the Polling Interval 101

Disabling the Windows Time Service. 101

Managing Long-Disconnected Domain Controllers. 101

Preparing a Domain Controller for a Long Disconnection. 107

Reconnecting Long-Disconnected Domain Controllers. 108

Removing Lingering Objects from an Outdated Writable
Domain Controller 111

Removing Lingering Objects from a Global Catalog Server 115

Managing Trusts. 117

Creating External Trusts. 118

Creating Shortcut Trusts. 119

Removing Manually Created Trusts. 120

Preventing Unauthorized Privilege Escalation. 120

Managing Sites. 121

Adding a New Site. 124

Adding a Subnet to the Network. 125

Linking Sites for Replication. 125

Changing Site Link Properties. 126

Moving a Domain Controller to a Different Site. 127

Removing a Site. 128

Troubleshooting Active Directory. 131

Overview of Active Directory Troubleshooting. 132

Prerequisites for Troubleshooting Active Directory. 135

Tools for Troubleshooting Active Directory. 136

High-level Methodology for Troubleshooting Active Directory Problems. 139

Documenting the Problem... 140

Identifying the Components Involved. 142

Verifying Client Health. 143

Verifying Network Path. 143

Verifying Server Health. 144

Verifying Service Health. 144

Iterate the Troubleshooting Process. 144

Troubleshooting High CPU Usage on a Domain Controller 145

Troubleshooting High CPU Usage by Processes. 146

Troubleshooting High CPU Usage on a PDC Emulator 147

Troubleshooting High CPU Usage on a Global Catalog Server 149

Troubleshooting High CPU Usage Caused by Excessive Client Load. 150

Troubleshooting Server-Related High CPU Usage. 152

Troubleshooting Active Directory–Related DNS Problems. 153

Troubleshooting Active Directory Replication Failure Due to
Incorrect DNS Configuration. 155

Troubleshooting Domain Controller Locator DNS Records
Registration Failure. 157

Troubleshooting Active Directory Installation Wizard Failure to
Locate Domain Controller 158

Troubleshooting Failure to Locate Domain Controller when
Attempting to Join a Domain. 158

Troubleshooting FRS. 159

Troubleshooting FRS Events 13508 without FRS Event 13509.. 161

Troubleshooting FRS Event 13511.. 162

Troubleshooting FRS Event 13522.. 163

Troubleshooting FRS Event 13526.. 163

Troubleshooting FRS Event 13548.. 163

Troubleshooting FRS Event 13557.. 164

Troubleshooting FRS Event 13567.. 164

Troubleshooting FRS Event 13568.. 164

Troubleshooting Files Not Replicating. 166

Verifying the FRS Topology in Active Directory. 167

Troubleshooting Morphed Folders. 168

Troubleshooting the SYSVOL Directory Junction. 169

Troubleshooting Excessive Disk and CPU Usage by NTFRS.EXE. 170

Troubleshooting Active Directory Replication Problems. 171

Troubleshooting No Inbound Neighbors Repadmin.exe Error 174

Troubleshooting Access Denied Replication Errors. 174

Troubleshooting GUID Discrepancies. 175

Troubleshooting RPC Server Problems. 176

Troubleshooting NTDS Event ID 1311.. 177

Troubleshooting SceCli Event ID 1202.. 179

Troubleshooting Active Directory Installation Wizard Problems. 180

Troubleshooting “Access Denied” Error Messages in Active Directory
Installation Wizard. 182

Troubleshooting Domain Naming Master Errors in Active Directory
Installation Wizard. 183

Troubleshooting Directory Data Problems. 184

Troubleshooting Lost Domain Objects. 184

Troubleshooting Object Name Conflicts. 185

Troubleshooting Windows Time Service Problems. 186

Troubleshooting Windows Time Service Errors on a PDC Emulator 187

Introduction

This operations guide provides guidance on how to manage and troubleshoot Microsoft® Windows® 2000 Active Directory. These activities are part of the operating phase of the IT life cycle. Although this guide specifically addresses the operating phase of the IT life cycle, Microsoft Enterprise Services Framework provides guidelines for other phases of the life cycle. These phases are listed in Table 1.1.

Table 1.1   IT Life Cycle and Microsoft Enterprise Services Frameworks Assistance

For this Phase…	Microsoft Enterprise Services Frameworks Provides this Assistance…
Planning	Although not currently a dedicated Enterprise Services framework, Microsoft Business Value Services provide tools to assess and plan the IT infrastructure, prioritize projects, and make a compelling business case for undertaking an IT project.
Building and Deploying	Microsoft Solutions Framework provides guidelines for building and deploying a project. The phases involved in this part of the IT lifecycle include Envisioning, Planning, Developing, and Deploying.
Operating	Microsoft Operations Framework provides guidelines for managing production systems within complex distributed IT environments.

Active Directory operations occur after you plan, build, and deploy your Active Directory implementation.

Note

All references to Windows 2000 include both Microsoft® Windows® 2000 Server and Microsoft® Windows® 2000 Advanced Server, unless otherwise specified. This document assumes that you are using Windows 2000 with Service Pack 2 (SP2) or greater.

Using the Microsoft Operations Framework for Active Directory Operations

Microsoft Operations Framework (MOF) is a collection of best practices, principles, and models. It provides comprehensive technical guidance for achieving reliable, available, supportable, and manageable solutions and services built on Microsoft products and technologies. MOF bases its recommendations on current industry best practices for IT service management, as documented and validated by the IT Infrastructure Library (ITIL) of the Central Computer and Telecommunications Agency (CCTA).

The MOF process model describes an operations life cycle that applies to releases of any size, relating to any service solution. MOF identifies four main areas of operations, which are divided into quadrants in the operations life cycle. Table 1.2 lists the four quadrants and the area of operations they cover.

Table 1.2   MOF Operations Quadrants

Quadrant	Service Mission
Operating	Perform day-to-day tasks effectively and efficiently.
Supporting	Resolve incidents, problems, and inquiries quickly.
Optimizing	Optimize cost, performance, capacity, and availability in the delivery of IT services and drive necessary changes, based on the data that you collect.
Changing	Introduce new service solutions, technologies, systems, applications, hardware, and processes.

This guide includes processes for operating Active Directory.

For more information about MOF, see the MOF link on the Web Resources page at <A HREF="http://go.microsoft.com/fwlink/?linkid=291" TARGET="_blank">http://www.microsoft.com/windows/reskits/webresources</A>.

Audience

This guide is for medium and large organizations that have one or more centralized IT operations departments. It includes information that is relevant to different roles within an IT organization, including IT Operations management and administrators. It contains high-level information that is required in planning an Active Directory operations environment. This information requires management-level knowledge of the technology and IT processes.

In addition, this guide contains low-level procedures that are designed for operators who have varied levels of expertise and experience. Although the procedures provide operator guidance from start to finish, operators must have a basic proficiency with the Microsoft Management Console (MMC) and snap-ins, and know how to start programs and access the command line.

Using this Guide

To accommodate a wide IT audience, the operations areas are divided into the following types of content:

· Overview, which explains what you need to consider for operating an Active Directory component, along with a list of tasks involved in operating that component.

· Tasks, which contain the caveats that you should be aware of when performing the task, along with a list of procedures involved in the task. For your convenience, a list of tasks and procedures appears in alphabetical order in Appendix A.

· Procedures, which appear in full in Appendix B of this document, and are often referred to by more than one task. All tasks in this document link to the associated procedures.

For maximum benefit in using this guide:

· Read through the entire Operating Active Directory chapter to gain a management-level knowledge of how to operate Active Directory.

· Ensure that you have all the tools installed where operators use them.

· Use the task lists to schedule recurring tasks.

· Create “tear sheets” for each task that operators perform within your organization. Cut and paste the task and its related procedures into a separate document and then either print these documents, or store them online, depending on the preference of your organization.

· Give the operator the tear sheets for the task when a task needs to be performed, along with information relevant to the environment (such as the name and IP address of the domain controller involved in the task).

Chapter Number 1

Managing Active Directory

Microsoft® Windows® 2000 Active Directory provides a robust directory service environment that requires few regularly scheduled maintenance tasks. However, you might perform some tasks on a regular basis, including backing up the database, and adding or removing domain controllers. You can use this guide to help you efficiently operate your Active Directory environment.

In This Chapter

Overview of Active Directory Operations

Monitoring Active Directory

Active Directory Backup and Restore

Managing Domain Controllers

Managing Trusts

Managing Sites

Overview of Active Directory Operations

The goal of operations is to ensure that IT services are delivered according to service level requirements that are agreed to by IT management and its various customer business units. The day-to-day operations of an IT department are proactive, and require that the proper products and services be in place to identify and prevent potential problems.

Planning for Active Directory Operations

To plan your Active Directory operations environment, you need to perform the following tasks:

· Assess the IT environment and establish a baseline.

· Determine operational needs.

· Define operations actions.

Assessing the IT Environment and Establishing a Baseline

You must have a complete and accurate idea of the details behind each service that the IT department delivers in order to properly configure management systems and technologies, and to collect any necessary metric data.

Review any service specifications that were produced during the deployment process, along with any service level requirements defined in Service Level Agreements between the IT organization and customer business units.

The following information is especially useful when planning your operations:

· Server specifications

· Network specifications

· Logical and physical architectural diagrams

· Supported applications

· User statistics and requirements

· Current thresholds and performance metrics

· Acceptable performance and outage times

This data provides a starting point to establish a baseline for the operations environment, and to set the proper level of service.

Determining Operational Needs

The Active Directory operations team must establish processes for the following tasks:

· Continuous monitoring and reporting

· Auditing

· Backup and restoration

· Managing Active Directory components, including:

u· Domain controllers (including issues relating to installation, global catalog servers, operations masters, database, SYSVOL, Windows Time Service, and long-disconnected domain controllers)

u· Trusts

u· Sites

Defining Operations Actions

Categorize actions that are performed during the course of day-to-day operations as follows:

· Automated actions

· Operator-driven actions

Automated Actions

Automated actions provide a time-saving method to detect and react to incidents occurring in the production environment. Identify those tasks and procedures that you want to automate, whether with scripts or a monitoring product such as Microsoft Operations Manager 2000 (MOM). Also identify the triggers, such as alerts generated by MOM, which start the automated action.

An example of an automated action is configuring an agent process to respond when it detects that the threshold for disk space has been exceeded. In this case, the agent process running on the affected computer automatically takes action to resolve the situation, such as deleting all the files in the Temp directory, thereby returning the system to acceptable conditions as defined in the Service Level Agreement. The agent system also sends a message to the management server that includes any necessary event data (the name and address of the affected system, the error message, the results of the action taken, and so on). After the automated action resolves the incident, the operations team can determine what, if any, further action to take. In this example, the automated action temporarily resolves the incident, and the operations team must investigate further to determine a permanent resolution.

Operator-Driven Actions

Operator-driven actions are those that are performed by an operator, as opposed to those performed by an automated system. Operator-driven actions need to be defined whenever and wherever possible, so that operators with varying degrees of skills and training can perform specific tasks, such as changing a password, loading forms into a printer, starting or stopping processes, and so on.

Tools Used for Active Directory Operations

Active Directory operations involves using tools that are either part of the Windows 2000 operating system, the Windows 2000 Support Tools, or the Microsoft® Windows® 2000 Server Resource Kit. Table 1.3 lists the tools that are used to operate Active Directory, where the tools are found, and a brief description of the purpose of the tool.

For information about installing the Windows 2000 Support Tools and the Windows 2000 Administrative Tools Pack, see Windows 2000 Server Help.

Table 1.3   Tools Used in Active Directory Operations

Tool	Location	Function
Active Directory Migration Tool (ADMT)	http://www.microsoft.com/windows2000/downloads/tools/ADMT/default.asp	Migrate account and resource domains.
Active Directory Domains and Trusts snap-in	Windows 2000 Administrative Tools Pack	Administer domain trusts, add user principal name suffixes, and change the domain mode.
Active Directory Installation Wizard	Windows 2000	Install Active Directory, and promote or demote domain controllers.
Active Directory Sites and Services snap-in	Windows 2000 Administrative Tools Pack	Administer the replication of directory data.
Active Directory Users and Computers snap-in	Windows 2000 Administrative Tools Pack	Administer and publish information in the directory.
ADSI Edit, MMC snap-in	Windows 2000 Support Tools	View, modify, and set access control lists on objects in the directory.
Backup Wizard	Windows 2000 system tool	Back up and restore data.
Control Panel	Windows 2000	View and modify computer, application, and network settings.
Dcdiag.exe	Windows 2000 Support Tools and Windows 2000 Server Resource Kit	Analyze the state of domain controllers in a forest or enterprise; assist in troubleshooting by reporting any problems.
DNS snap-in	Windows 2000 Administrative Tools Pack	Manage DNS.
Dsastat.exe	Windows 2000 Support Tools	Compare directory information on domain controllers and detectsdifferences.
Event viewer	Windows 2000 Administrative Tools Pack	Monitor events recorded in event logs.
Lbridge.cmd	Windows 2000 Server Resource Kit	Replicate logon scripts and profiles between Windows 2000–based domain controllers and Windows NT 4.0–based domain controllers.
Ldp.exe	Windows 2000 Support Tools	Perform LDAP operations against Active Directory.
Linkd.exe	Windows 2000 Server Resource Kit	Create, delete, update, and view the links that are stored in junction points.
MMC	Windows 2000	Create, save, and open administrative tools (called MMC snap-ins) that manage hardware, software, and network components.
Netdiag.exe	Windows 2000 Server Resource Kit and Windows 2000 Support Tools	Check end-to-end network connectivity and distributed services functions.
Netdom.exe	Windows 2000 Support Tools	Allow batch management of trusts, joining computers to domains, and verifying trusts and secure channels.
Net use, start, stop, del, copy, time	Windows 2000 system tool	Perform common tasks on network services, including stopping, starting, and connecting to network resources.
Nltest.exe	Windows 2000 Support Tools	Verify that the locator and secure channel are functioning.
Notepad	Windows 2000 Accessories	View, create, and modify text files.
Ntdsutil.exe	Windows 2000 system tool	Manage Active Directory, manage single master operations, remove metadata, create application directory partitions.
Regedit.exe	Windows 2000 system tool	View and modify registry settings.
Repadmin.exe	Windows 2000 Support Tools	Verify replication consistency between replication partners, monitor replication status, display replication metadata, and force replication events and topology recalculation.
Replmon.exe	Windows 2000 Support Tools	Display replication topology, monitor replication status, and force replication events and topology recalculation.
Services snap-in	Windows 2000 Administrative Tools Pack	Start, stop, pause, or resume system services on remote and local computers, and configures startup and recovery options for each service.
Terminal Services	Windows 2000	Access and manage computers remotely.
W32tm	Windows 2000 system tool	Manage Windows Time Service.
Windows Explorer	Windows 2000	Access files, Web pages, and network locations.

Operations Tasks Checklist

Table 1.4 provides a quick reference for those product maintenance tasks that the operations team must perform on a regular basis. These task lists summarize the tasks that are required to maintain Active Directory operations.

Table 1.4   Active Directory Operations Tasks

Frequency	Tasks
Daily.	Verify that all domain controllers are communicating with the central monitoring console or collector.
Daily.	View and examine all new alerts on each domain controller, resolving them in a timely fashion.
Daily.	Resolve alerts indicating the following services are not running: FRS, Net Logon, KDC, W32Time, ISMSERV. MOM reports these as Active Directory Essential Services.
Daily.	Resolve alerts indicating SYSVOL is not shared.
Daily.	Resolve alerts indicating that the domain controller is not advertising itself.
Daily.	Resolve alerts indicating time synchronization problems.
Daily.	Resolve all other alerts in order of severity. If alerts are given error, warning, and information status similar to the event log, resolve alerts marked error first.
Daily to weekly, depending on environment.	Identify a site that has no global catalog server.
Weekly.	Review the Time Synchronization Report to detect intermittent problems and resolve time-related alerts.
Weekly.	Review the Authentication Report to help resolve problems generated by computer accounts with expired passwords.
Weekly.	Review the Duplicate Service Principal Name Report to list all security principals that have a service principal name conflict.
Weekly.	Review a report of the top alerts generated by the Active Directory monitoring indicators and resolve those items that occur most frequently.
Weekly.	Review the report that lists all trust relationships in the forest and check for obsolete, unintended, or broken trusts.
Monthly.	Verify that all domain controllers are running with the same service pack and hot fix patches.
Monthly.	Review all Active Directory reports and adjust thresholds as needed. Examine each report and determine which reports, data, and alerts are important for your environment and service level agreement.
Monthly.	Review the Replication Monitoring Report to verify that replication throughout the forest occurs within acceptable limits
Monthly.	Review the Active Directory response time reports.
Monthly.	Review the domain controller disk space reports.
Monthly.	Review all performance related reports. These reports are called Health Monitoring reports in MOM.
Monthly.	Review all performance related reports for capacity planning purposes to ensure that you have enough capacity for current and expected growth. These reports are called Health Monitoring reports in MOM.
Monthly.	Adjust performance counter thresholds or disable rules that are not applicable to your environment or that generate irrelevant alerts.
Monthly.	Identify the global catalog servers in a site.
At least twice within the tombstone lifetime.	Back up Active Directory and associated components.
As needed.	Perform a non-authoritative restore.
As needed.	Perform an authoritative restore of a subtree or leaf object.
As needed.	Perform an authoritative restore of the entire directory.
As needed.	Recover a domain controller through reinstallation.
As needed.	Restore a domain controller through reinstallation and subsequent restore from backup.
As needed.	Prepare for Active Directory Installation.
As needed.	Install Active Directory.
As needed.	Perform Active Directory post-installation tasks.
As needed.	Decommission a domain controller.
As needed.	Identify the current configuration of a domain controller.
As needed.	Rename a domain controller.
As needed.	Restore the original configuration of a domain controller.
As needed.	Add the global catalog to a domain controller and verify global catalog readiness.
As needed.	Remove the global catalog from a domain controller.
As needed.	Designate operations master roles.
As needed.	Reduce the workload on a PDC emulator.
As needed.	Decommission an operations master role holder.
As needed.	Seize operations master roles.
As needed.	Choose a standby operations master.
As needed.	Relocate directory database files.
As needed.	Return unused disk space from the directory database to the file system.
As needed.	Speed removal of an expired-tombstone backlog.
As needed.	Change the space allocated to the Staging Area folder.
As needed.	Relocate the Staging Area folder.
As needed.	Move SYSVOL by using the Active Directory Installation Wizard.
As needed.	Move SYSVOL manually.
As needed.	Update the SYSVOL path.
As needed.	Restore and rebuild SYSVOL.
As needed.	Configure a time source for the forest.
As needed.	Configure a reliable time source on a computer other than the PDC emulator.
As needed.	Configure a client to request time from a specific time source.
As needed.	Optimize the polling interval.
As needed.	Disable the Windows Time Service.
As needed.	Prepare a domain controller for long disconnection.
As needed.	Reconnect a long-disconnected domain controller.
As needed.	Remove lingering objects from an outdated writable domain controller.
As needed.	Remove lingering objects from a global catalog server.
As needed.	Create an external trust (between a Windows 2000 domain and a Windows NT 4.0 domain, or between domains in different forests).
As needed.	Create a shortcut trust.
As needed.	Remove a manually created trust.
As needed.	Prevent unauthorized privilege escalation.
As needed.	Add a new site.
As needed.	Add a subnet to the network.
As needed.	Link sites for replication.
As needed.	Change site link properties.
As needed.	Move a domain controller to a different site.
As needed.	Remove a site.

Monitoring Active Directory

Monitoring the distributed Active Directory service and the services that it relies upon helps maintain consistent directory data and the needed level of service throughout the forest. You can monitor important indicators to discover and resolve minor problems before they develop into potentially lengthy service outages. Most large organizations with many domains or remote physical sites require an automated monitoring system such as Microsoft Operations Manager 2000 (MOM) to monitor important indicators. An automated monitoring system provides the necessary consolidation and timely problem resolution to administer Active Directory successfully.

Benefits for End-Users

Monitoring Active Directory helps resolve issues in a timely manner, and users experience the following benefits:

· Improved reliability of productivity applications that rely on back-end servers, such as e‑mail.

· Quicker logon time and more reliable resource usage.

· Decreased help desk support issues.

Benefits for Administrators

Monitoring Active Directory provides administrators with a centralized view of Active Directory across the entire forest. By monitoring important indicators, administrators can realize the following benefits:

· Higher customer satisfaction, because issues can be resolved before users notice problems.

· Increased service levels, due to improved reliability and system understanding.

· Greater schedule flexibility and ability to prioritize workload, due to early notification of problems, allowing resolution of issues while they are still a lower priority.

· Increased ability for the system to cope with periodic service outages.

Monitoring Active Directory also assures administrators that:

· All necessary services that support Active Directory are running on each domain controller.

· Data is consistent across all domain controllers and end-to-end replication completes in accordance with your service level agreements.

· Lightweight Directory Access Protocol (LDAP) queries respond quickly.

· Domain controllers do not experience high CPU usage.

· The central monitoring console collects all events that can adversely affect Active Directory.

Risks of not Monitoring Active Directory

Systematic monitoring is necessary to ensure consistent service delivery in a large environment with many domain controllers, domains, or physical sites. As a distributed service, Active Directory relies upon many interdependent services distributed across many devices and in many remote locations. As you increase the size of your network to take advantage of the scalability of Active Directory, monitoring becomes more important. It helps you avoid potentially serious problems, including:

· Logon failure. Logon failure can occur throughout the domain or forest if a trust relationship or name resolution fails, or if a global catalog server cannot determine universal group membership.

· Account lockout. User and service accounts can become locked out if the PDC emulator is unavailable in the domain or replication fails between several domain controllers.

· Domain Controller failure. If the drive containing the Ntds.dit file runs out of disk space, the domain controller stops functioning.

· Application failure. Applications that are critical to your business, such as Microsoft Exchange or another e-mail application, can fail if address book queries into the directory fail.

· Inconsistent directory data. If replication fails for an extended period of time, objects (known as lingering objects and re-animated objects) can be created in the directory and might require extensive diagnosis and time to eliminate.

· Account creation failure. A domain controller is unable to create user or computer accounts if it exhausts its supply of relative IDs and the RID master is unavailable.

· Security policy failure. If the SYSVOL shared folder does not replicate properly, Group Policy objects and security policies are not properly applied to clients.

Levels of Monitoring

Use a cost-benefit analysis to determine the degree or level of monitoring that you need for your environment. Compare the cost of formalizing a monitoring solution with the costs associated with service outages and the time that is required to diagnose and resolve problems that might occur. The level of monitoring also depends on the size of your organization and your service level needs.

Organizations with few domains and domain controllers, or that do not provide a critical level of service, might only need to periodically check the health of a single domain controller by using the built-in tools provided in Windows 2000 Server.

Larger organizations that have many domains, domain controllers, sites, or that provide a critical service and cannot afford the cost of lost productivity due to a service outage, need to use an enterprise-level monitoring solution such as MOM.

Enterprise-level monitoring solutions use agents or local services to collect the monitoring data and consolidate the results on a central console. Enterprise-level monitoring solutions also take advantage of the physical network topology to reduce network traffic and increase performance. In a complex environment, directory administrators need enterprise-level monitoring to derive meaningful data and to make good decisions and analysis. For more information about MOM, see http://www.microsoft.com/mom/.

Active Directory Monitoring During the Deployment Phase

As a best practice, deploy monitoring with the first domain controller. By integrating monitoring into the design and deployment process, you can avoid many of the problems that arise during deployment. Because monitoring solutions require network connectivity between the monitored servers and the management consoles, you must account for particular TCP/IP ports and bandwidth usage.

As with any sophisticated service, implement a monitoring solution such as MOM in a lab before you deploy it in a production environment.

Service-Level Baseline

A baseline represents service level needs as performance data. By setting thresholds to indicate when the baseline boundaries are exceeded, your monitoring solution can generate alerts to inform the administrator of degraded performance and jeopardized service levels. For example, you can use performance indicators to set a baseline and monitor for low disk space on the disk drives that contain the Active Directory database and log files, and you can monitor CPU usage of a domain controller. You can also monitor critical services running on a domain controller. Monitoring these indicators allows the administrator to ensure adequate performance.

To determine an accurate baseline, monitor and collect data for a time period that is long enough to represent peak and low usage. For example, monitor during the time in the morning when the greatest number of users log on. Monitor for an interval that is long enough to span your password change policy and any month-end or other periodic processing that you perform. Also, collect data when network demands are low to determine this minimal level. Be sure to collect data when your environment is functioning properly. To accurately assess what is acceptable for your environment, remove data caused by network outages or other failures when you establish your baseline.

The baseline that you establish for your environment can change over time as you add new applications, users, hardware, and domain infrastructure to the environment, and as the expectations of users change. Over time, the directory administrator might look for trends and changes that occur, and take actions designed to meet the increased demands on the system and maintain the desired level of service. Such actions might include fine-tuning the software configuration and adding new hardware.

Determining the thresholds when alerts are generated to notify the administrator that the baseline has been exceeded is a delicate balance between providing either too much information or not enough. The vendor of your monitoring solution, such as MOM, can provide general performance thresholds, but you must periodically adjust these thresholds to meet your service level requirements. To adjust these thresholds, first collect and analyze the monitoring data to determine what is acceptable or usual activity for your environment. After you gather a good data sample and consider your service level needs, you can set meaningful thresholds that trigger alerts.

To determine thresholds:

· For each performance indicator, collect monitoring data and determine the minimum, maximum and average values.

· Analyze the data with respect to your service level needs.

· Adjust thresholds to trigger alerts when indicators cross the parameters for acceptable service levels.

As you become more familiar with the monitoring solution you choose, it becomes easier to correlate the thresholds that trigger the alerts to your service level delivery. If you are uncertain, it is usually better to set the thresholds low to view a greater number of alerts. As you understand the alerts you receive and determine why you receive them, you can increase the threshold at which alerts are generated, thereby reducing the amount of information that you receive from your monitoring solution. MOM uses thresholds that are a reasonable starting point and work for the majority of medium-sized customers. Larger organizations might need to increase the thresholds.

Requirements for Monitoring

Managing an enterprise-level directory requires monitoring many important indicators. Failure to monitor all of the important indicators can create gaps in coverage. Use any monitoring solution that best suits your needs, but monitor the necessary important indicators to ensure that all aspects of Active Directory are functioning properly. MOM monitors all of the important indicators.

For more information about monitoring Active Directory see: http://www.microsoft.com/ad.

For more information about MOM, see: http://www.microsoft.com/mom/.

For more information about installing MOM, see http://www.microsoft.com/mom/docs/DeployGuide.doc.

Relationship between Monitoring and Troubleshooting

The goal of a comprehensive monitoring solution is to monitor all of the important indicators and provide alerts that are concise, highly relevant, and lead an operator to resolve the problem. Ideally, the monitoring solution alerts the operator only when a problem requires action. In this case, monitoring alerts are the first indicator that a problem exists. If the operator cannot easily resolve the problem that generated an alert, you might want to create a help desk ticket to begin troubleshooting and root-cause analysis. Your monitoring solution can initiate your troubleshooting processes or flowcharts.

Monitoring helps ensure that the Active Directory service is available for service requests. Active Directory is designed to be fault tolerant and can continue to operate if individual servers are unavailable for periodic maintenance or while operators troubleshoot them. You can assure a high-degree of reliability by monitoring the distributed services that make up Active Directory, and resolving issues as they develop.

In addition to providing increased service availability, the relationship between monitoring and troubleshooting increases your understanding of the root causes of most problems that arise. As your environment becomes more reliable, monitoring alerts more precisely indicate the cause of new problems that arise.

Reports

Many important problems do not cause alerts, but they still require periodic attention. Your monitoring solution might generate reports that display data over time and present patterns that indicate problems. Review the reports to resolve issues before they generate alerts.

Frequency of Monitoring Tasks

You can perform the daily, weekly, and monthly tasks as specified in the following tables, but you must adjust the frequency to meet the needs of your particular environment and monitoring solution.

Daily Monitoring Tasks

Table 1.5   Daily Tasks and Their Importance

Tasks	Importance
Verify that all domain controllers are communicating with the central monitoring console or collector.	Communication failure between the domain controller and the monitoring infrastructure prevents you from receiving alerts so you can examine and resolve them.
View and examine all new alerts on each domain controller, resolving them in a timely fashion.	This precaution helps you avoid service outages.
Resolve alerts indicating the following services are not running: FRS, Net Logon, KDC, W32Time, ISMSERV. MOM reports these as Active Directory Essential Services.	Active Directory depends on these services. They must be running on every domain controller.
Resolve alerts indicating SYSVOL is not shared.	Active Directory cannot apply Group Policy unless SYSVOL is shared.
Resolve alerts indicating that the domain controller is not advertising itself.	Domain controllers must register DNS records to be able to respond to LDAP and other service requests.
Resolve alerts indicating time synchronization problems.	The Kerberos authentication protocol requires that time be synchronized between all domain controllers and clients that use it.
Resolve all other alerts in order of severity. If alerts are given error, warning, and information status similar to the event log, resolve alerts marked error first.	The highest priority alerts indicate the most serious risk to your service level..

Weekly Monitoring Tasks

Table 1.6   Weekly Tasks and Their Importance

Tasks	Importance
Review the Time Synchronization Report to detect intermittent problems and resolve time-related alerts.	The Kerberos authentication protocol requires that time be synchronized between all domain controllers and clients that use it.
Review the Authentication Report to help resolve problems generated by computer accounts with expired passwords.	Expired passwords must be reset to allow the computers to authenticate and participate in the domain.
Review the Duplicate Service Principal Name Report to list all security principals that have a service principal name conflict.	User or computer accounts cannot be authenticated or log on if they share an SPN with another account.
Review a report of the top alerts generated by the Active Directory monitoring indicators and resolve those items that occur most frequently.	Report shows alerts that occur most often. Focusing on the top alert generators significantly reduces the number of alerts seen by the operator.
Review the report that lists all trust relationships in the forest and check for obsolete, unintended, or broken trusts.	Authentication between domains or forests requires trust relationships.

Monthly Monitoring Tasks

Table 1.7   Monthly Tasks and Their Importance

Tasks	Importance
Verify that all domain controllers are running with the same service pack and hot fix patches.	Potential issues can arise if distributed services are running with different versions of software.
Review all Active Directory reports and adjust thresholds as needed. Examine each report and determine which reports, data, and alerts are important for your environment and service level agreement.	Examining the data that is relevant to your environment allows you to determine the thresholds that trigger the alerts to your service level delivery.
Review the Replication Monitoring Report to verify that replication throughout the forest occurs within acceptable limits	Timely replication helps assure that you meet your service level agreements.
Review the Active Directory response time reports.	Services must respond quickly for the system to function properly and applications such as e-mail to work properly.
Review the domain controller disk space reports.	The drives containing the Active Directory database and log files must have sufficient free space to accommodate growth and routine processing.
Review all performance-related reports. These reports are called Health Monitoring reports in MOM.	These reports can help you determine the baseline for your environment and adjust thresholds.
Review all performance-related reports for capacity planning purposes to ensure that you have enough capacity for current and expected growth. These reports are called Health Monitoring reports in MOM.	These reports help you track growth trends in your environment and plan for future hardware and software needs.
Adjust performance counter thresholds or disable rules that are not applicable to your environment or that generate irrelevant alerts.	Monitoring indicators must be adjusted to suit your environment. The goal is to provide alerts that are concise, highly relevant, and lead an operator to resolve the problem.

Active Directory Backup and Restore

Active Directory is backed up as part of system state, a collection of system components that depend on each other. You must back up and restore system state components together.

Components that comprise the system state on a domain controller include:

· System Start-up Files (boot files). These are the files required for Windows 2000 Server to start.

· System registry.

· Class registration database of Component Services. The Component Object Model (COM) is a binary standard for writing component software in a distributed systems environment.

· SYSVOL. The system volume provides a default Active Directory location for files that must be shared for common access throughout a domain. The SYSVOL folder on a domain controller contains:

· NETLOGON shared folders. These usually host user logon scripts and Group Policy objects (GPOs) for non‑Windows 2000–based network clients.

· User logon scripts for Windows 2000 Professional–based clients and clients that are running Windows 95, Windows 98, or Windows NT 4.0.

· Windows 2000 GPOs.

· File system junctions.

· File Replication service (FRS) staging directories and files that are required to be available and synchronized between domain controllers.

· Active Directory. Active Directory includes:

· Ntds.dit: The Active Directory database.

· Edb.chk: The checkpoint file.

· Edb*.log: The transaction logs, each 10 megabytes (MB) in size.

· Res1.log and Res2.log: Reserved transaction logs.

Note

If you use Active Directory‑integrated DNS, then the zone data is backed up as part of the Active Directory database. If you do not use Active Directory‑integrated DNS, you must explicitly back up the zone files. However, if you back up the system disk along with the system state, zone data is backed up as part of the system disk.

If you installed Windows Clustering or Certificate Services on your domain controller, they are also backed up as part of system state. Details of these components are not discussed in this guide.

General Guidelines for Backup

The backup tool in Windows 2000 Server supports multiple types of backup: normal, copy, incremental, differential, and daily. However, because Active Directory is backed up as part of system state, the only type of backup available for Active Directory is normal. A normal backup creates a backup of the entire system state while the domain controller is online. In addition, the backup tool marks each file as a backed up file, which clears the archive attribute of the file.

Considerations for ensuring a good backup

To ensure a successful restore from backup, you must know what defines a good backup.

_{Which domain controllers to back up}

At a minimum, back up two domain controllers in each domain, one of which should be an operations master role holder (excluding the relative ID (RID) master, which should not be restored). Note that backup data from a domain controller can only be used to restore that domain controller. You cannot use a backup of one domain controller to restore another.

_Contents

A good backup includes at least the system state and the contents of the system disk. Backing up the system disk ensures that all the required system files and folders are present so you can successfully restore the data.

Note

Best performance practice states that the Active Directory’s logs and database files should be on separate disks. If you have configured your domain controllers in this manner you will have Active Directory components spread out on multiple drives, such as D:\Winnt\NTDS for your logs and E:\Winnt\NTDS for your database. You do not need to specify these log and database locations in order for them to be backed up; the backup utility will automatically locate and include them when you back up system state.

_Age

A backup that is older than the tombstone lifetime set in Active Directory is not a good backup. At a minimum, perform at least two backups within the tombstone lifetime. The default tombstone lifetime is 60 days. Active Directory incorporates the tombstone lifetime into the backup and restore process as a means of protecting itself from inconsistent data.

Deleting an object from Active Directory is a two-step process. When an object is deleted in Active Directory, the object gets converted into a tombstone, which is then replicated to the other domain controllers in the environment to inform them of the deletion. Active Directory purges the tombstone when the tombstone lifetime is reached.

If you restore a domain controller to a state prior to the deletion of an object, and the tombstone for that object is not replicated to the restored domain controller before the tombstone expires, the object remains present only on the restored domain controller, resulting in inconsistent data. Thus, you must restore the domain controller prior to expiration of the tombstone, and allow inbound replication from a domain controller containing the tombstone to complete prior to expiration of the tombstone.

Active Directory protects itself from restoring data older than the tombstone lifetime by disallowing the restore. As a result, the useful life of a backup is equivalent to the tombstone lifetime setting for the enterprise.

General Guidelines for Restore

You can start the restore process by using either the Windows 2000 Server backup utility or another supported utility. You can perform either a non-authoritative restore or an authoritative restore.

How to Select the Appropriate Restore Method

You select the appropriate restore method by considering:

· Circumstances and characteristics of the failure. The two major categories of failure, from an Active Directory perspective, are Active Directory data corruption and hardware failure. Active Directory data corruption occurs when the directory contains corrupt data that has been replicated to all domain controllers or when a large portion of the Active Directory hierarchy has been changed accidentally (such as deletion of an OU) and this change has replicated to other domain controllers.

· Roles and functions of the failed server.

Non-authoritative restore of Active Directory

A non-authoritative restore returns the domain controller to its state at the time of backup, then allows normal replication to overwrite that state with any changes that have occurred after the backup was taken. After you restore the system state, the domain controller queries its replication partners. The replication partners replicate any changes to the restored domain controller, ensuring that the domain controller has an accurate and updated copy of the Active Directory database.

Non-authoritative restore is the default method for restoring Active Directory, and you will use it in most situations that result from Active Directory data loss or corruption. To perform a non-authoritative restore, you must be able to start the domain controller in Directory Services Restore Mode.

Non-authoritative restore of SYSVOL

When you non-authoritatively restore the SYSVOL, the local copy of SYSVOL on the restored domain controller is compared with that of its replication partners. After the domain controller restarts, it contacts its replication partners, compares SYSVOL information, and replicate the any necessary changes, bringing it up-to-date with the other domain controllers within the domain.

Perform a non-authoritative restore of SYSVOL if at least one other functioning domain controller exists in the domain. This is the default method for restoring SYSVOL and occurs automatically if you perform a non-authoritative restore of the Active Directory.

If no other functioning domain controller exists in the domain, then perform a primary restore of the SYSVOL. A primary restore builds a new File Replication service (FRS) database by loading the data present under SYSVOL on the local domain controller. This method is the same as a non-authoritative restore, except that the SYSVOL is marked primary.

Authoritative restore of Active Directory

An authoritative restore is an extension of the non-authoritative restore process. You must perform the steps of a non-authoritative restore before you can perform an authoritative restore. The main difference is that an authoritative restore has the ability to increment the version number of the attributes of all objects in an entire directory, all objects in a subtree, or an individual object (provided that it is a leaf object) to make it authoritative in the directory. Restore the smallest unit necessary, for example, do not restore the entire directory in order to restore a single subtree.

As with a non-authoritative restore, after a domain controller is back online, it will contact its replication partners to determine any changes since the time of the last backup. However, because the version number of the object attributes that you want to be authoritative will be higher than the existing version numbers of the attribute held on replication partners, the object on the restored domain controller will appear to be more recent and therefore will be replicated out to the rest of the domain controllers within the environment.

Unlike a non-authoritative restore, an authoritative restore requires the use of a separate tool, Ntdsutil.exe. No backup utilities — including the Windows 2000 Server system tools — can perform an authoritative restore.

An authoritative restore will not overwrite new objects that have been created after the backup was taken. You can authoritatively restore only objects from the configuration and domain-naming contexts. Authoritative restores of schema-naming contexts are not supported.

Perform an authoritative restore when human error is involved, such as when an administrator accidentally deletes a number of objects and that change replicates to the other domain controllers and you cannot easily recreate the objects. To perform an authoritative restore, you must start the domain controller in Directory Services Restore Mode.

Authoritative restore of SYSVOL

By authoritatively restoring the SYSVOL, you are specifying that the copy of SYSVOL that is restored from backup is authoritative for the domain. After the necessary configurations have been made, Active Directory marks the local SYSVOL as authoritative and it is replicated to the other domain controllers within the domain.

The authoritative restore of SYSVOL does not occur automatically after an authoritative restore of Active Directory. Additional steps are required.

As with Active Directory authoritative restore, you typically perform an authoritative restore of SYSVOL when human error is involved and the error has replicated to other domain controllers. For example, you might perform an authoritative restore of SYSVOL if an administrator has accidentally deleted an object that resides in SYSVOL, such as a Group Policy object.

Recover a domain controller through reinstallation

To recover a domain controller through reinstallation, you do not restore the system state from backup media; instead, you reinstall Windows, install Active Directory, and allow replication partners to bring the recovered domain controller up to date.

Recovering a domain controller through reinstallation can quickly return the computer to service if the following conditions exist:

· A domain controller has failed and you cannot restart in Directory Services Restore mode. If failure was caused by a hardware failure, you have resolved the hardware problem (for example, by replacing the disk).

· There are other domain controllers in the domain, to serve as replication partners.

· The computer is functioning only as a domain controller (it does not run other server services such as Exchange), and it does not contain other data that needs to be recovered from a backup.

Restore a domain controller through reinstallation and restore from backup

This method involves first reinstalling Windows 2000, to enable you to start in Directory Services Restore Mode. During the Windows 2000 Server setup process, you will obtain more information about the nature of the failure and you can then determine whether you can reinstall Windows 2000 Server into the same partition as it was previously installed or whether you will need to re-partition the drive. After you successfully reinstall Windows 2000, you can start in Directory Services Restore Mode and perform a normal non-authoritative restore from backup media.

Restore a domain controller through reinstallation and restore the system state from backup if the following conditions exist:

· A domain controller has failed and you cannot restart in Directory Services Restore mode. If failure was caused by a hardware failure, you have resolved the hardware problem (for example, by replacing the disk).

· You have the following information about the failed domain controller:

· Disk configuration. You need a record of the volumes and sizes of the disks and partitions. You use this information to recreate the disk configuration in the case of a complete disk failure. You must recreate all disk configurations prior to restoring system state. Failure to recreate all disk configurations can cause the restore process to fail and can prevent you from starting the domain controller following the restore.

· Computer name. You need the computer name to restore a domain controller of the same name and avoid changing client configuration settings.

· Domain membership. You must know the domain name because even if the computer name does not change, you might need to re-establish a new computer account.

· Local Administrator password. You must know the local computer’s Administrator password that was used when the backup was created. Without it, you will not be able to log on to the computer to establish a domain account for the computer after you restore it. If you are not part of the domain, you will not be able to log on by using a domain account, even if you are a domain administrator. The local Administrator password is also required to restore the system state on a domain controller.

· The domain controller is running other server services such as Exchange, or contains other data you must restore from a backup.

· You have a good backup, made within the tombstone lifetime.

Considerations for restoring operations masters

To restore an operations master role holder, you must perform one of the following procedures:

· Restore the failed operations master from backup.

· Seize the role to another domain controller within the environment. Seize the operations master role only if you do not intend to restore the original role holder from backup. For more information about seizing operations master roles, see “Managing Operations Masters” in this guide.

Restoring the RID Master can result in Active Directory data corruption, so it is not recommended.

Restoring the Schema Master can result in orphaned objects, so it is not recommended.

Considerations for recovering global catalog servers

To recover the global catalog server you can either:

· Restore the failed global catalog server from backup.

· Assign a new global catalog to compensate for the loss of the original.

Restoring from backup is the only way that a domain controller that was functioning as a global catalog at the time of backup can automatically be restored to the role of global catalog. Restoring a domain controller by reinstallation does not automatically reinstate the global catalog role. In a multi-domain environment, be aware that restoring a global catalog server from backup requires more time than restoring a domain controller that does not host the global catalog.

As there are no real disadvantages in configuring multiple global catalogs, you might want to create a new global catalog in your environment if you anticipate an extended downtime for the failed global catalog server. Creating a new global catalog server is particularly relevant if users associated with the original global catalog server can no longer access a global catalog server, or if the requirement for the global catalog service is significant in your environment, such as when you are running Exchange 2000.

For more information about creating a new global catalog server, see “Managing Global Catalogs Servers” in this guide.

Note

Configuring multiple global catalogs servers in a forest increases the availability of the system, but also increases replication traffic and database size. If you do restore the failed domain controller and maintain its role as a global catalog server, you might want to remove any additional global catalogs servers that you configured during its absence.

Considerations for restoring onto different hardware

It is possible to restore a domain controller onto different hardware. However, you should consider the following issues:

· Different hardware abstraction layers (HALs). By default, the Hal.dll is not backed up as part of system state, however the Kernel32.dll is. Therefore, if you try to restore a backup onto a computer that requires a different HAL (for example, to support a multiprocessor environment) compatibility issues exist between the new HAL and the original Kernel32.dll. To overcome this incompatibility, manually copy the Hal.dll from the original computer and install it on the new computer. The limitation is that the new computer can use only a single processor.

· Incompatible Boot.ini File. If you backup and restore the boot.ini file, you might have some incompatibility with your new hardware configuration, resulting in a failure to start. Before you restore it, ensure that the boot.ini file is correct for your new hardware environment.

· Different Network or Video Cards. If your new hardware has a different video adapter or multiple network adapters, then uninstall them before you restore data. When you restart the computer; the normal Plug and Play functionality makes the necessary changes.

· Disk Space and Partition Configuration. Partitions on the new computer must match those on the original computer. Specifically, all the drive mappings must be the same and the partition size must be at least equal to that on the original computer.

Considerations for authoritative restores

Performing an authoritative restore can affect group membership and passwords for trusts and computer accounts.

_{Impact on group membership}

By performing an authoritative restore, you risk possible loss of group membership information.

Because group membership is a multi-valued attribute, and because of how Active Directory handles links, back links and deletions, an authoritative restore can produce varying results to group membership. These variations are based on which objects replicate first after an authoritative restore: the User object or the Group object.

If the un-deletion of the user replicates first, then the group membership information of both the group (the members it contains) and the user (the groups to which the user belongs) will be represented correctly.

If the un-deletion of the group replicates first, the replication partners will drop the addition of the (locally) deleted user from the group membership. The only exception to this is the user’s primary group, which is always represented correctly both from the user and group reference.

You cannot control which object replicates first after you perform an authoritative restore. If your environment is affected by this situation, the only option is to modify the group membership attribute of the affected groups on the domain controller where you performed the authoritative restore.

This issue stems not from the integrity of the restored data, but from the way in which the data is replicated. By looking at this domain controller, administrators can view the way the directory should look and take steps to replicate the accurate directory information to the other domain controllers within the domain.

The best way to do this is to add a fictitious user and then delete that same fictitious user to and from each group that was involved in the authoritative restore.

A group is involved in the restore if it was either authoritatively restored itself or if it had members restored who did not have that group defined as their primary group.

By doing this, you force the correct group membership information to be replicated out from the source domain controller (the domain controller on which you performed the original authoritative restore) and update the group membership information on its replication partners. These updated objects reflect the correct memberships and also correct the information represented in the Member of tab of the restored user objects’ properties.

You must ensure that no additions are made to group membership (for the affected groups and users) on any of the other domain controllers within the environment.

If you do not adhere to this process, the accurate version of the directory (held on the domain controller where the restore was performed) can become corrupted by the incorrect membership information. If the accurate version of the directory becomes corrupted, you must either update group membership manually or perform another authoritative restore of the objects by using the verinc option, and perform the process again.

_{Impact on trusts and computer accounts}

In Windows 2000, trust relationships and computer account passwords are negotiated at a specified interval (by default 30 days for trust relationships and computer passwords).

When you perform an authoritative restore, you might restore previously used passwords for the objects in the Active Directory that maintain trust relationships and computer accounts.

In the case of trust relationships, this can impact communication with other domain controllers from other domains, causing permissions errors when users try to access resources in other domain. To rectify this, you must remove and recreate NTLM trust relationships to Windows 2000 or Windows NT 4.0 domains.

In the case of a computer account password, this can impact communications between the member workstation or server and a domain controller of its domain. This effect might cause users on Windows NT or Windows 2000 computers to have authentication difficulty due to an invalid computer account.

Backup and Restore Tasks and Procedures

Table 1.8 shows the tasks and procedures for backup and restore.

Table 1.8   Backup and Restore Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Back up Active Directory and associated components.	· Back up system state on a domain controller. · Back up system state and system disk on a domain controller.	· NTBackup.exe	At least twice within the tombstone lifetime
Perform a non-authoritative restore.	· Restart the domain controller in Directory Services Restore Mode (locally or remotely). · Restore from backup media. · Verify Active Directory restore.	· NTBackup.exe · Ntdsutil.exe · Event Viewer · Repadmin.exe	As needed
Perform an authoritative restore of a subtree or leaf object.	· Restart in Directory Services Restore Mode. · Restore from backup media for authoritative restore. · Restore system state to an alternate location. · Perform authoritative restore of the subtree or leaf object. · Restart in normal mode. · Restore applicable portion of SYSVOL from alternate location. · Verify Active Directory restore.	· NTBackup.exe · Ntdsutil.exe · Event Viewer · Repadmin.exe	As needed
Perform an authoritative restore of the entire directory.	· Restart in Directory Services Restore Mode. · Restore from backup media for authoritative restore. · Restore system state to an alternate location. · Restore the database. · Restart in normal mode. · Copy SYSVOL from alternate location. · Verify Active Directory restore.	· NTBackup.exe · Ntdsutil.exe · Event Viewer · Repadmin.exe	As needed
Recover a domain controller through reinstallation.	· Clean up metadata. · Install Windows 2000 Server. · Install Active Directory.	· Ntdsutil.exe · Active Directory Sites and Services · Active Directory Users and Computers · Dcpromo.exe	As needed
Restore a domain controller through reinstallation and subsequent restore from backup.	· Install Windows 2000 Server on the same drive letter and partition as before the failure, partitioning the drive if necessary. · Restore from backup media (non-authoritative restore). · Verify Active Directory restore.	· NTBackup.exe	As needed

Backing Up Active Directory and Associated Components

To back up Active Directory and associated components on a domain controller, you can back up only system state or you can back up both system state and the system disk.

Procedures for Backing Up Active Directory and Associated Components

Use one of the following procedures to back up Active Directory and associated components. Procedures are explained in detail in the linked topics.

1. Back up system state.

2. Back up system state and the system disk.

Performing a Non-Authoritative Restore

Non-authoritative restore is the default method for restoring Active Directory, and you use it in most situations that result from Active Directory data loss or corruption. You must be able to start in Directory Services Restore Mode to perform a non-authoritative restore. After you restore the domain controller from backup media, replication partners use the standard replication protocols to update both the Active Directory and FRS on the restored domain controller.

Procedures for Performing a Non-Authoritative Restore

Use the following procedures to perform a non-authoritative restore of a domain controller. Procedures are explained in detail in the linked topics.

1. Restart the domain controller in Directory Services Restore Mode (locally or remotely).

2. Restore from backup media.

3. Verify Active Directory restore.

Performing an Authoritative Restore of a Subtree or Leaf Object

An authoritative restore of a subtree or leaf object restores that subtree or leaf and marks it as authoritative for the directory. You begin by restoring from backup media, just as in a non-authoritative restore, but then you perform additional steps to complete an authoritative restore.

Procedures for Authoritative Restore of a Subtree or Leaf Object

Use the following procedures to perform an authoritative restore of an Active Directory subtree or leaf object. Procedures are explained in detail in the linked topics.

1. Restart the domain controller in Directory Services Restore Mode (locally or remotely).

2. Restore from backup media for authoritative restore.

3. Restore system state to an alternate location.

4. Perform authoritative restore of the subtree or leaf object.

5. Restore applicable portion of SYSVOL from alternate location if necessary.

6. Verify Active Directory restore.

Performing an Authoritative Restore of Entire Directory

Authoritative restore of the entire directory is a major operation. Perform an authoritative restore of the entire directory only after consultation with a Microsoft Support professional. Do not perform an authoritative restore of the entire directory if only one domain controller exists in the domain.

Procedures for Authoritative Restore of the Entire Directory

Use the following procedures to perform an authoritative restore of the entire Active Directory. Procedures are explained in detail in the linked topics.

1. Restart the domain controller in Directory Services Restore Mode (locally or remotely).

2. Restore from backup media.

3. Restore system state to an alternate location.

4. Perform authoritative restore of entire directory.

5. Restore SYSVOL from alternate location.

6. Verify Active Directory restore.

Recovering a Domain Controller Through Reinstallation

Recovering through reinstallation is the same process as creating a new domain controller. It does not involve restoring from backup media. This method relies on Active Directory replication to restore a domain controller to a working state, and is only valid if another healthy domain controller exists in the same domain. This option is normally used on computers that function only as a domain controller.

Bandwidth Considerations

The primary consideration when recovering a domain controller through replication is bandwidth. The bandwidth required is directly proportional to the size of the Active Directory database and the time in which the domain controller is required to be at a functioning state. Ideally, the existing functional domain controller is located in the same Active Directory site as the replicating domain controller (new domain controller) in order to reduce network impact and restore duration.

Procedures for Recovering a Domain Controller Through Reinstallation

Use the following procedures to recover a domain controller. Procedures are explained in detail in the linked topics.

1. Clean up metadata.

2. Reinstall Windows 2000 Server. (This procedure is not covered in this guide.)

3. Install Active Directory. During the installation process, replication occurs, ensuring that the domain controller has an accurate and up to date copy of the Active Directory. For more information about seizing operations master roles, see “Installing Active Directory” in this guide.

Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup

If you cannot restart a domain controller in Directory Services Restore Mode, you can restore a domain controller through reinstallation and subsequently restore Active Directory from backup. This option is normally used on domain controllers that also run other services, such as Exchange, or have other data you want to recover.

Procedures for Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup

To restore a domain controller through reinstallation and subsequently restore Active Directory from backup, you must ensure that you install Windows 2000 Server on the same drive letter and on a partition that is at least as large as the partition used before the failure. You must repartition the drive if necessary. After you reinstall Windows 2000, perform a non-authoritative restore of the system state and the system disk. Procedures are explained in detail in the linked topics.

1. Install Windows 2000 Server on the same drive letter and partition as before the failure. (This procedure is not covered in this guide.)

2. Restore from backup media.

3. Verify Active Directory restore.

Managing Domain Controllers

While individual domain controllers require little management, your overall operations environment might require change-related tasks, such as adding or removing domain controllers, or reintroducing a domain controller that has been offline for more than one replication cycle. During your day-to-day operations, you might need to do some or all of the following:

· Install and remove Active Directory

· Rename domain controllers

· Manage global catalog servers

· Manage operations masters

· Manage the database

· Manage SYSVOL

· Manage Windows Time Service

· Manage long-disconnected domain controllers

Installing and Removing Active Directory

Only domain controllers can host Active Directory. All servers that are not domain controllers must access the directory in the same manner as the workstations. They send requests for information to a domain controller, which processes the request and returns the information back to them.

Domain controllers store and maintain portions of the directory. They also have services that allow them to directly store and retrieve information from the directory. These services are referred to as the Active Directory. When you install Active Directory on a Windows 2000–based server, it becomes a Windows 2000–based domain controller.

The process of removing Active Directory involves steps similar to those for installation. You run many of the same tests before you remove the directory as you run before you install the directory. These tests ensure that the process occurs without any problems. In the event that a domain controller suffers a hardware failure and you plan to never return it to service, you must take additional steps to remove it from the directory.

The Active Directory Installation Wizard

You install Active Directory by running the Active Directory Installation Wizard on a Windows 2000–based server. The wizard simplifies the process by automating as much of the installation process as possible. During the installation, the wizard asks for the name of the domain that you want this domain controller to host, and for the location where you want to install required files. To run the Active Directory Installation Wizard, you must be a member of the Domain Admins group.

Active Directory Installation Prerequisites

This guide covers the installation of Active Directory in an environment that is configured according to the best practices described in Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks. To download these guides, see the Active Directory link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. They describe the process of planning your forests and domains and provide recommendations for deploying DNS. They also provide guidelines for estimating the number of domains as well as the number of domain controllers in each domain.

Before you begin your installation, the following conditions must exist in your environment:

· Your Active Directory forest must already exist. At least two properly functioning domain controllers must reside in the forest root.

· Your Active Directory Domain must already exist. At least two properly functioning domain controllers must reside in the domain.

· DNS must be functioning properly.

· You must use Active Directory–integrated DNS zones. You must configure at least one domain controller as a DNS server.

Note

Creating or removing a domain or forest is beyond the scope of this guide. This guide does not cover deploying DNS into an environment that has not previously hosted a DNS infrastructure.

For information about these options, see the Active Directory link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources and the Microsoft® Windows® 2000 Server Deployment Planning Guide.

Active Directory Installation Preparation

Properly preparing for the installation of Active Directory decreases the chances of problems during the installation process and helps you quickly complete the operation. Preparation includes installing and configuring DNS and gathering information that you need for the installation.

Configure all domain controllers as DNS servers. Install the DNS server service prior to installing Active Directory. Follow the recommendations mentioned earlier so that your domain is already configured, DNS is functioning, and you have Active Directory–integrated DNS zones. Installing the DNS Server service prior to installing Active Directory allows the DNS Server service to automatically start using the DNS zones that are stored on the directory after you complete the Active Directory installation.

The installation wizard asks for specific configuration information, such as the domain administrator’s user name and password, location of the directory database and log files, and the password needed to us Directory Services Restore Mode, before it begins installing Active Directory. Have that information ready before you run the Active Directory Installation Wizard.

Note

For better performance, store the log files and the Ntds.dit file on separate hard disks.

Active Directory Installation

During the installation, the Active Directory Installation Wizard communicates with other domain controllers to obtain configuration information. This information can come from any domain controller in the same domain. The Active Directory Installation Wizard also communicates with the various operations masters so that the new domain controller can properly join the domain and be added to the directory. For this process to succeed, the wizard must be able to communicate with the various domain controllers involved. Test these channels of communication prior to installing Active Directory to help ensure that the process does not encounter problems during the installation.

After successfully testing the communication paths, the Active Directory Installation Wizard installs Active Directory on the server to make it a domain controller. During the installation process, the wizard asks for the information that you gathered during the preparation phase. After the wizard finishes, it restarts the domain controller and the installation completes during the restart process.

Active Directory Post-installation Tasks

After you complete the installation of Active Directory, perform some validation tests to ensure that the domain controller is properly joined to the domain and is functioning as expected. The areas you must test include:

· Site placement

· DNS configuration

· Network connectivity

· SYSVOL

· Replication

If your tests show that all of these areas are configured and functioning properly, the Active Directory installation is successful.

Active Directory Unattended Installation

You can automate the Active Directory installation process by performing an unattended installation. You can create an answer file to answer the questions that the Active Directory Installation Wizard asks during the installation. The installation does not require user input and proceeds quickly.

For more information about unattended installation options, see “Using the Answer File with the Active Directory Installation Wizard” in the Deployment Planning Guide.

Domain Controller Removal

A domain controller can be removed from a domain in one of two ways: by removing Active Directory or by a system failure that renders the domain controller inoperable so that you cannot restore it to service.

Active Directory removal

Similarly to how you can install Active Directory to turn a Windows 2000–based server into a domain controller, you can remove Active Directory and turn a Windows 2000–based domain controller back into a server. This process removes most of the references to the domain controller from the directory. You must manually remove the server object that represents the domain controller from the computer container after you remove Active Directory. This method properly removes the domain controller from the directory.

Domain controller failure

A hardware failure on a domain controller can render it inoperable. If the problem is severe enough, you might never be able to return the domain controller to service. In this case, the other domain controllers eventually reconfigure themselves so that they can continue to replicate directory information without the failed domain controller.

When a domain controller is removed from the domain without removing Active Directory, all the information about that domain controller remains in the directory. You must take additional steps to remove this information from the directory.

Active Directory Installation and Removal Management Tasks and Procedures

Table 1.9 shows the tasks and procedures for managing Active Directory installation and removal.

Table 1.9   Active Directory Installation and Removal Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Prepare for Active Directory Installation.	· Install the DNS Server service. · Gather installation information.	· Control Panel	As needed.
Install Active Directory.	· Verify DNS registration and functionality. · Verify that an IP address maps to a subnet and determine the site association. · Verify communication with other domain controllers. · Verify the existence of operations masters. · Install Active Directory.	· Dcdiag.exe and Netdiag.exe · Dcpromo.exe	As needed.
Perform Active Directory post-installation tasks.	· Determine whether a server object has child objects. · Verify the site assignment of a domain controller. · Move a domain controller to a different site. · Configure DNS server recursive name resolution. · Perform final DNS configuration. · Check the status of the shared system volume. · Verify DNS registration and functionality. · Verify domain membership for the new domain controller. · Verify communication with other domain controllers. · Verify replication is functioning. · Verify the existence of the operations masters.	· Active Directory Sites and Services · DNS snap-in · Dcdiag.exe and Netdiag.exe	As needed.
Decommission a domain controller.	· View the current operations master role holders. · Transfer the forest-level operations master roles. · Transfer the domain-level operations master roles. · Determine whether a domain controller is a global catalog server. · Verify DNS registration and functionality. · Verify communication with other domain controllers. · Verify the existence of the operations masters. · Remove Active Directory. · Determine whether a server object has child objects. · Delete a server object from a site.	· Active Directory Users and Computers · Active Directory Sites and Services · Dcdiag.exe and Netdiag.exe · Dcpromo.exe	As needed.

Preparing for Active Directory Installation

Preparation helps the Active Directory installation proceed successfully. To prepare for the installation process, you must have the appropriate domain information and credentials available before you start the Active Directory Installation Wizard. It is recommended that you configure all domain controllers as DNS servers. You must have your DNS server configuration information available for that portion of the installation process.

DNS Service Installation

Domain controllers use DNS to locate other domain controllers that are hosting Active Directory. Configure every domain controller as a DNS server to help ensure that a DNS server is always available. Using Active Directory–integrated DNS zones simplifies the configuration required because you do not need to create the zone files on each DNS server. Active Directory–integrated zones are stored in the directory and are replicated to each domain controller along with other Active Directory data. When you start a domain controller that also runs DNS, the DNS Server service detects the zones in the directory and uses them.

Before you install DNS server on a domain controller that you want to host Active Directory–integrated zones, ensure that you already have other domain controllers functioning in the domain with at least one configured as a DNS server that uses Active Directory–integrated zones.

For more information about DNS configuration and operations master role placement, see Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks. To download these guides, see the Active Directory link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Active Directory Installation Information

Gather the information that you must supply to the Active Directory Installation Wizard before you run the wizard.

Procedures for Preparing for Active Directory Installation

To prepare for the Active Directory installation, install the DNS Server service on the server that you want to make a domain controller and gather the information that you must supply to the Active Directory Installation Wizard.

1. Install the DNS Server service.

2. Gather installation information, including:

· The user name, password, and the domain that contains the user account that you intend to use to run the Active Directory Installation Wizard.

· The name of the domain that you want the new domain controller to host.

· Location for the Active Directory database (Ntds.dit).

· Location for the log files.

· Location for the Shared System Volume (SYSVOL).

· The server administrator account name and password to use in Directory Services Restore mode.

Installing Active Directory

You install Active Directory by using the Active Directory Installation Wizard (DCPromo.exe). During installation, the wizard contacts other domain controllers for information that it needs to complete the installation. If the wizard cannot communicate with other domain controllers, the installation fails. To help ensure successful installation, test the communication channels prior to running the wizard.

Site Placement

During installation, the Active Directory Installation Wizard attempts to place the new domain controller in the appropriate site. The appropriate site is determined by the domain controller’s IP address and subnet mask. The wizard uses the IP information to calculate the subnet address of the domain controller and checks to see if a subnet object exists in the directory for that subnet address. If the subnet object exists, the wizard uses it to place the new server object in the appropriate site. If not, the wizard places the new server object in the same site as the domain controller that is being used as a source to replicate the directory database to the new domain controller. Make sure the subnet object has been created for the desired site prior to running the wizard.

Domain Connectivity

During the installation process, the Active Directory Installation Wizard needs to communicate with other domain controllers in order to join the new domain controller to the domain. The wizard needs to communicate with a member of the domain to receive the initial copy of the directory database for the new domain controller. It needs to communicate with the domain naming master so that the new domain controller can be added to the domain. The wizard also needs to contact the RID master so that the new domain controller can receive its RID pool, and it needs to communicate with another domain controller in order to populate the SYSVOL shared folder on the new domain controller. All of this communication depends on proper DNS installation and configuration. By using Netdiag.exe and Dcdiag.exe, you can test all of these connections prior to starting the Active Directory Installation Wizard.

The Active Directory Installation Wizard

After you have gathered all the information that you need to run the Active Directory Installation Wizard and performed the tests to verify that all of necessary domain controllers are available, you are ready to install Active Directory on your server and turn it into a domain controller.

You need to log on with local administrative credentials to start the wizard. Start the wizard and supply the information you gathered earlier. If the wizard asks for information that you did not gather, such as if you want to install DNS Server service, it is indicating that it cannot locate the DNS servers. The wizard assumes that none exist and asks you if you want to install one. Running the verification tests prior to using the installation wizard helps prevent this kind of situation from happening.

During the installation process, the wizard asks for information that it needs to properly configure the new domain controller. First, it asks is if you want to install a domain controller in a new domain or an additional domain controller in an existing domain. Because this guide pertains to adding domain controllers to domains that already exist, choose Additional domain controller in an existing domain.

During the installation process, the wizard needs to communicate with other domain controllers in order to add this new domain controller to the domain and get the appropriate information into the Active Directory database. To maintain security, you must provide credentials that have administrative access to the directory. Once your credentials are validated, the wizard guides you through the following steps:

· The wizard asks for a user name, password, and domain name of the account it uses to add this domain controller to the directory.

· The wizard then asks for the name of the domain that you want this new domain controller to host. Enter the fully qualified domain name of the appropriate domain.

· Next, the wizard asks where you want to store the Active Directory database and the database log files. For better performance, store these files on separate hard disks.

· The wizard then asks for the location where you want to store the shared System Volume (SYSVOL). Ensure that the location has adequate disk space. For more information about ensuring adequate disk space for SYSVOL, see “Managing Sysvol” later in this guide.

· The wizard then asks for the password that is assigned to the Directory Services Restore Mode administrator account. This account is not the domain administrator account or the local administrator account on the server, but a special account that can only be used when the domain controller starts in Directory Services Restore Mode.

· Before installation begins, the wizard displays a dialog box that summarizes the information that you supplied. Verify that the information is correct before the installation process begins.

Procedures for Installing Active Directory

1. Verify DNS registration and functionality.

2. Verify that an IP address maps to a subnet and determine the site association.

3. Verify communication with other domain controllers.

4. Verify the existence of the operations masters.

Note

If any of the verification tests fail, do not continue until you determine and fix the problems. If these tests fail, the installation is also likely to fail.

5. Install Active Directory.

Performing Active Directory Post-Installation Tasks

After completing the installation of Active Directory, perform some validation tests to ensure that the domain controller is properly installed into the domain and is functioning as expected. Successfully passing these tests is a good indication that the new domain controller is functioning properly. You might also need to perform additional tasks regarding DNS configuration and hosting the global catalog.

Proper Site Placement

You must ensure that the new domain controller is located in the proper site so that after the installation is complete, the new domain controller can locate replication partners and become part of the replication topology. During Active Directory installation, the wizard creates a server object for the new domain controller in the directory and attempts to place the server object in the proper site. To place the server object, the wizard uses the current IP address and subnet mask of the new domain controller. If the subnet associated with the domain controller’s IP address is not defined by an existing subnet object, the wizard places the new server object in the same site as the source domain controller, which is the domain controller from which the new domain controller downloaded a copy of the directory database. If the site is not correct, you can use the Active Directory Sites and Services snap-in to move the server object for the domain controller to the proper site after Active Directory installation is complete.

The last dialog box displayed by the Active Directory Installation Wizard lists the site where the new domain controller is installed. If this is not the proper site, you need must move the server object.

For more information about sites or to create a new site object, see “Managing Site Topology” later in this guide.

Final DNS Configuration

If you installed the DNS server service and made this domain controller a DNS server, you might need to perform some additional configuration of the DNS installation to ensure that it conforms to the recommended practices. The configuration that you must perform depends upon whether this is a new domain controller in the forest root domain or a new domain controller in a child domain. Performing final DNS configuration helps balance the load among your DNS servers and provides redundancy in case a DNS server becomes unavailable.

You might need to add a delegation for the new domain controller. If your forest root domain is a child domain in your corporate DNS domain structure, you must add a delegation for the new domain controller in the forest root’s parent DNS domain. If the forest root domain has no parent DNS domain, you do not need to add the delegation.

If the new domain controller is located in a child domain of the forest root domain, you must add a delegation for the new domain controller to the forest root domain.

You also need to configure the DNS client settings on the new domain controller. Configure a domain controller in the forest root domain to refer to another DNS server located nearby as its primary DNS server and refer to itself as the secondary DNS server. If the new domain controller is located in a child domain of the forest root domain, configure the DNS client to use its own IP address as its primary DNS server address, and another local DNS server as the secondary server address.

If the new domain controller is located in a child domain below the forest root, create a secondary zone to make the process of locating domain controllers more reliable.

Whether or not the new domain controller is located in a parent or child domain, you must also configure the DNS server to use either root hints or forwarders for recursive name resolution. Follow the established method on your network.

Domain Connectivity

After the Active Directory Installation Wizard finishes, the domain controller restarts and performs a few tasks before it is ready to assume its role as a domain controller. It registers itself with its DNS server so that other members of the domain know that it is a domain controller and can locate it.

When a new domain controller first joins the network, it receives SYSVOL information from its replication partners. Until it finishes the initial replication of the SYSVOL, it does not create the NETLOGON and SYSVOL shared folders and does not start the Net Logon service, both of which are necessary for it to assume the role of a domain controller. An event number 13516 in the File Replication Service event log indicates that replication is complete and is working properly. At this point, the domain controller starts the Net Logon service and the domain controller becomes available to the domain.

Note

This process can take 15 minutes or longer to complete, depending on the connection speed between the domain controller and its replication partners.

Domain controllers make changes to the directory and replicate these changes among themselves through a series of connections that are established when the domain controller joins the network. The connections can be generated automatically or an administrator might manually create the connections objects. If these connections are not functioning properly, the domain controller cannot replicate changes to the other domain controllers and cannot receive changes from other domain controllers.

To function properly, domain controllers must periodically communicate with various operations masters. The domain controllers send password changes to the PDC emulator. They receive a RID pool from the RID master. As their pools are depleted, the domain controller periodically replenishes their allocations by sending requests to the RID master.

All of these features depend upon communication between the new domain controller and other domain controllers in the domain and forest. When a new domain controller joins the network, perform tests that verify the communication channels used by these features.

Configure Other Roles

After the domain controller is functioning properly and you complete verification tests and final DNS configuration, configure any additional roles, such as global catalog server, on the domain controller. For information about configuring a global catalog server, see “Managing Global Catalog Servers” later in this guide.

Procedures for Performing Active Directory Post-Installation Tasks

To perform this task, the site object must already be defined in Active Directory Sites and Services and you must know the site in which you want to place the server object.

1. Determine whether a server object has child objects.

2. Verify the site assignment for the domain controller.

3. Move a server object to a different site if the domain controller is located in the wrong site.

4. Configure DNS server recursive name resolution.

5. Perform final DNS configuration for a new domain controller that is located in the forest root domain:

a. Create a delegation for the new domain controller in the parent domain of the DNS infrastructure if a parent domain exists and a Microsoft DNS server hosts it. If a Microsoft DNS server does not host the parent domain, follow the procedures outlined in the vendor documentation to add the delegation for the new domain controller.

b. Configure the DNS client settings.

– or –

Perform final DNS configuration for a new domain controller that is located in a child domain:

c. Create a delegation for the new domain controller in the forest root domain.

d. Create a secondary zone.

e. Configure the DNS client settings.

6. Check the status of the shared system volume.

7. Verify DNS registration and functionality.

8. Verify domain membership for the new domain controller.

9. Verify communication with other domain controllers.

10. Verify replication is functioning.

11. Verify the existence of the operations masters.

Decommissioning a Domain Controller

Just as you can install Active Directory to make a Windows 2000–based server a domain controller, you can also remove Active Directory and to make a Windows 2000–based domain controller back into a server.

Removing Active Directory is a similar process to installing it. You use the Active Directory Installation Wizard and it contacts other domain controllers to copy information from the domain controller that you want to decommission. As with installation, if the domain controller cannot contact the other domain controllers during the Active Directory removal, the process is likely to fail. Perform the same connectivity tests prior to decommissioning a domain controller as you perform prior to installing Active Directory.

This guide does not include procedures for decommissioning the last domain controller in a domain. Decommissioning the last domain controller in a domain constitutes the removal of the domain from the forest. For more information about removing domains, see “Removing Active Directory” in the Windows 2000 Server Distributed Systems Guide.

Operations Master Role Transfer

During the decommissioning process, the Active Directory Installation Wizard transfers the operations master roles to other domain controllers without any user interaction. You do not have control over which domain controller receives the roles. The wizard transfers the roles to any available domain controller and does not indicate which domain controller hosts them.

Because of this behavior, transfer any operations master roles prior to running the Active Directory Installation Wizard to decommission a domain controller so you can control operations master role placement. If you need to transfer any roles from a domain controller, understand all the recommendations for role placement before performing the transfer. For more information about transferring operations master roles and role placement, see “Managing Operations Master Roles” later in this guide.

Global Catalog Removal

If you remove Active Directory from a domain controller that hosts the global catalog, the Active Directory Installation Wizard confirms that you want to continue with removing Active Directory. This confirmation ensures that you are aware that you are removing a global catalog from your environment. Do not remove the last global catalog server from your environment because users cannot logon without an available global catalog server. If you are not sure, do not proceed with removing Active Directory until you know at least one other global catalog server is available. For more information about removing and creating global catalog servers, see “Managing Global Catalog Servers” later in the guide.

Domain Connectivity

During the removal of Active Directory, the Active Directory Installation Wizard must communicate with various domain controllers. Any unreplicated changes to the directory must be replicated to another domain controller. The wizard attempts to connect to another domain controller to replicate these changes. The wizard must contact another domain controller so that Active Directory can remove the domain controller from the directory database. If the domain controller hosts any operations master roles that you chose not to transfer, the wizard must contact another domain controller in order to transfer the operations master roles.

If the domain controller cannot contact the other domain controllers during Active Directory removal, the decommissioning operation fails. As with the installation process, test the communication infrastructure prior to running the installation wizard. When you remove Active Directory, use the same connectivity tests that you use during Active Directory installation.

Active Directory Removal

After you transfer operations master roles and verify that all the necessary domain controllers are available, you can use the Active Directory Installation Wizard to remove Active Directory. When you run the wizard on a server that is already a domain controller, it displays the Remove Active Directory options.

The wizard asks whether or not this is the last domain controller in the domain and requests the password that is assigned to the local administrator account on the server after Active Directory is removed. Note that the procedures in this guide do not pertain to removing Active Directory from the last domain controller in the domain, because that action also deletes the domain from the forest.

Server Object Removal

After removing Active Directory from a domain controller, the Active Directory Installation Wizard removes information about that domain controller from the directory. Because it no longer acts as a domain controller, the server is not part of the replication topology and the directory does not maintain connections to it. During the decommissioning process, the Active Directory Installation Wizard removes the server object from the Domain Controller container in Active Directory Users and Computers and removes the connection objects associated with the domain controller from the NTDS Settings object in Active Directory Sites and Services.

The Active Directory Installation Wizard does not delete the server object from the site object during the removal of Active Directory because other services, such as Microsoft Operations Manager 2000 (MOM), use this container to store their own site-specific information. After you remove Active Directory, you can use the Active Directory Sites and Services snap-in to safely remove the server object that represents the decommissioned domain controller in Active Directory Sites and Services if the server object container is empty.

Procedures for Decommissioning Domain Controllers

1. View the current operations master role holders to see if any roles are assigned to this domain controller.

2. Transfer the forest-level operations master roles to another domain controller in the forest root domain if this domain controller hosts either the schema master or domain naming master roles.

3. Transfer the domain-level operations master roles if this domain controller hosts the PDC emulator, infrastructure master, or RID master.

4. Determine whether a domain controller is a global catalog server to ensure that other domain controllers are configured as global catalog servers before you remove Active Directory.

5. Verify DNS registration and functionality.

6. Verify communication with other domain controllers.

7. Verify the existence of the operations masters.

Note

If any of the verification tests fail, do not continue until you determine and fix the problems. If these tests fail, the installation is also likely to fail.

8. Remove Active Directory.

9. Determine whether a server object has child objects.

10. Delete a server object from a site.

Renaming Domain Controllers

Renaming a domain controller that is running Windows 2000 Server involves the following steps:

u Removing Active Directory

u Renaming the computer

u Reinstalling Active Directory

u Restoring the domain controller to its original configuration

When you rename a domain controller, you must reinstall any services that cannot identify the computer name dynamically or that can only operate on a domain controller. You do not need to reinstall any of the services that ship with Windows 2000 Server, such as File and Print sharing or DNS.

It is recommended that you do not rename a domain controller unless it is absolutely necessary. For example, it would be necessary to rename a domain controller if:

· You moved the domain controller to another site and the name of the domain controller needs to map to the naming convention of the new site.

· The name of the domain controller was chosen in error; such as when the naming convention requires the site name and a derivative of the domain, but the name includes the incorrect site or domain.

Because renaming a domain controller requires that Active Directory be removed and then reinstalled on the computer, the impact on the network of renaming a domain controller is identical to the impact of installing Active Directory to create a new domain controller or global catalog server.

Renaming Domain Controllers Tasks and Procedures

Table 1.10 lists the tasks and procedures for renaming domain controllers.

Table 1.10   Tasks and Procedures for Renaming Domain Controllers

Tasks	Procedures	Tools	Recommended Frequency
Identify the current configuration of the domain controller.	· Determine whether the domain controller is a global catalog server. · View the operations master role holders. · Transfer forest-level operations master roles, if appropriate. · Transfer domain-level operations master roles, if appropriate. · Determine whether the domain controller is a DNS server. · Determine the initial change notification delay. · Determine whether the domain controller is a preferred bridgehead server.	· Active Directory Sites and Services · Ntdsutil.exe · Services · Regedit.exe	As needed.
Rename the domain controller.	· Remove Active Directory. · Rename the member server. · Run the Active Directory Installation Wizard.	· DCPromo.exe · System Control Panel	As needed.
Restore the original configuration of the domain controller.	· Configure the domain controller as a global catalog server, if appropriate. · Transfer the domain operations master roles, if appropriate. · Transfer the forest operations master roles, if appropriate. · Create a delegation for the new domain controller, if appropriate. · Create a secondary DNS zone, if appropriate. · Change the delay for initial notification of an intrasite replication partner, if appropriate. · Configure the domain controller as a preferred bridgehead server, if appropriate.	· Active Directory Sites and Services · Active Directory Users and Computers · Active Directory Domains and Trusts · Regedit.exe	As needed.

Identifying the Current Configuration of a Domain Controller

Because renaming a domain controller involves removing and reinstalling Active Directory, you must be able to reestablish the current configuration of the domain controller after you rename it. Before you begin, identify the current configuration of the domain controller so that you can restore it after you reinstall Active Directory. Specifically, determine the status of the following roles and configurations:

· Global catalog server. If the domain controller is a global catalog server, the global catalog partial directory partitions are removed when you remove Active directory. Therefore, after you rename the domain controller, you need to reconfigure the domain controller as a global catalog server. For information about configuring a domain controller as a global catalog server, see “Managing Global Catalog Servers” in this guide.

· Operations master role holder. If the domain controller holds operations master roles, it is recommended that you transfer the roles to the standby master for the roles prior to removing Active Directory. If you do not transfer the roles, they are transferred automatically, but you have no control over the placement of the roles. By manually transferring the roles prior to removing Active Directory, you control the role placement. For information about transferring operations master roles, see “Managing Operations Masters” in this guide.

· DNS server. Removing Active Directory does not remove the DNS Server service if it is installed. However, when you reinstall Active Directory, you need to reconfigure the domain controller to assume authority for the appropriate DNS zones and to contain all appropriate delegations. For information about configuring DNS server after installing Active Directory, see “Managing the Installation and Removal of Active Directory” in this guide.

· Initial change notification delay. This server-specific configuration determines how long the domain controller waits before it signals its first replication partner that it has changes. If you change the default initial change notification delay setting on the domain controller, you need to reconfigure the setting when you reinstall Active Directory.

· Preferred bridgehead server. This configuration is not recommended for domain controllers running Windows 2000 Server. However, if the domain controller is configured to be a preferred bridgehead server, you must reconfigure the domain controller as a preferred bridgehead server after you reinstall Active Directory. For more information about using preferred bridgehead servers, see “Managing Site Topology” in this guide.

Procedures for Identifying the Current Configuration of a Domain Controller

Use the following procedures to identify the current configuration of the domain controller. You need to reconfigure the current configuration on the renamed domain controller after you reinstall Active Directory.

1. Determine whether the domain controller is a global catalog server.

2. View the operations master role holders. If roles are held by this domain controller, transfer the roles to the standby operations master prior to removing Active Directory, as follows:

· If the domain controller holds any forest-level roles, transfer forest-level operations master roles.

· If the domain controller holds any domain-level roles, transfer domain-level operations master roles.

3. Determine whether the domain controller is a DNS server. Make a note of the DNS configuration so that you can reproduce it when you reinstall Active Directory.

4. Determine the initial change notification delay. If this setting has been changed from the default on this domain controller, you need to reconfigure the setting after you rename the server and add Active Directory.

5. Determine whether the domain controller is a preferred bridgehead server.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see “Active Directory Backup and Restore” in this guide.

Renaming a Domain Controller

Before you rename a domain controller, you must remove Active Directory to return the domain controller to member server status. Prior to performing this procedure, be sure that you have transferred any operations master roles that are held by the domain controller.

After you remove Active Directory, rename the member server and then reinstall Active Directory on the member server to restore it to domain controller status.

Procedures for Renaming a Domain Controller

Use the following procedures to rename a domain controller. You must perform these procedures directly on the domain controller; they cannot be performed remotely.

1. Remove Active Directory. This procedure results in the domain controller becoming a member server in the domain.

2. Rename the member server.

3. Run the Active Directory Installation Wizard. This procedure installs Active Directory on the member server to restore it to domain controller status.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see “Active Directory Backup and Restore” in this guide.

Restoring the Original Configuration of a Domain Controller

After you have renamed a member server and returned it to domain controller status, you must restore the original configuration of the domain controller.

If you transferred any domain operations master roles to another domain controller in the domain prior to renaming the domain controller, you can now transfer them back to the renamed domain controller.

If the domain controller was originally configured as a DNS server, you must restore the zone and delegation configurations. The following instructions are based upon best practice recommendations for DNS design, as described in “Best Practice Active Directory Design for Managing Windows Networks” and “Best Practice Active Directory Deployment for Managing Windows Networks” at http://windows.microsoft.com. Follow the links under Products to Windows 2000 Server, Technical Resources, Planning & Deployment, Deploying the Windows 2000 Server Family. If your deployment uses a different DNS design, you might not use the delegations and secondary zones described below.

If the domain controller is located in a child domain anywhere in the forest, then you must:

· Create a delegation for the domain controller in the forest root domain.

· Create a secondary zone.

If the domain controller is located in the forest root domain and the forest root domain has a parent domain, then you must:

· Create a delegation for the new domain controller in the parent domain.

For information about how to configure DNS servers after installing Active Directory, see “Completing Active Directory Installation” in this guide.

Procedures for Restoring the Original Configuration of a Domain Controller

Use the following procedures to restore a domain controller to its original configuration.

1. Configure the domain controller as a global catalog server, if appropriate.

2. Transfer the domain operations master roles, if appropriate.

3. Transfer the forest operations master roles, if appropriate.

4. Create a delegation for the new domain controller, if appropriate. Perform this procedure in the parent domain of the domain of the DNS server, if one exists.

5. Create a secondary DNS zone, if appropriate. Perform this procedure only if the DNS server is located in a child domain, not in the forest root domain.

6. Change the delay for initial notification of an intrasite replication partner, if appropriate.

7. Configure the domain controller as a preferred bridgehead server, if appropriate.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see “Active Directory Backup and Restore” in this guide.

Managing Global Catalog Servers

Designate global catalog servers in sites to accommodate forest-wide directory searching and so that Active Directory can determine universal group membership of native-mode domain clients.

Global Catalog Placement

To improve the speed of logging on and searching, place at least one global catalog server in each site, and at least two global catalog servers if the site has multiple domain controllers. As a best practice, make half of all domain controllers in a site global catalog servers if the site contains more than three domain controllers. If your deployment uses a single global domain, configure all domain controllers as global catalog servers. In a single-domain forest, configuring all domain controllers as global catalog servers requires no additional resources.

When placing global catalog servers, primary concerns are:

· Does any site have no global catalog servers?

· What domain controllers are designated as global catalog servers in a particular site?

Initial Global Catalog Replication

When you add a global catalog server to a site, the Knowledge Consistency Checker (KCC) updates the replication topology, after which replication of partial domain directory partitions that are available within the site begins. Replication of partial domain directory partitions that are available only from other sites begins at the next scheduled interval.

Adding subsequent global catalog servers within a site requires only intrasite replication and does not affect network performance. Replication of the global catalog potentially affects network performance only when adding the first global catalog server in the site, and the impact varies depending on the following conditions:

· The speed and reliability of the wide area network (WAN) link or links to the site.

· The size of the forest.

For example, in a forest that has a large hub site, five domains, and thirty small branch sites (some of which are connected by only dial-up connections), global catalog replication to the small sites takes considerably longer than replication of one or two domains to a few well-connected sites.

Global Catalog Readiness

After replication of the partial domain directory partitions, the domain controller advertises as a global catalog server and begins accepting queries on ports 3268 and 3269. The requirements for advertising as a global catalog server differ in Microsoft Windows 2000 Server Service Pack 3 (SP3) and in Windows 2000 Server Service Pack 2 (SP2). The default requirements in Windows 2000 Server SP3 include replication of all domain directory partitions in the forest. The default requirements in Windows 2000 Server SP2 are limited to replication of the domain directory partitions that are local to the site. If the domain controller advertises as a global catalog server before it has complete information from all domains in the forest, it might return false information to applications that begin using the server for forest-wide searches.

For example, Microsoft Exchange 2000 servers use the global catalog exclusively when looking up addresses. A domain controller that advertises as a global catalog server before it contains all partial directory partitions can cause Address Book lookup and mail delivery problems for Exchange clients. To avoid this problem, ensure that the domain controller does not advertise as global catalog server before it contains all partial domain directory partitions.

Premature advertisement of the global catalog is an issue only for global catalog servers that are running Windows 2000 Server SP2, and only when you add the first global catalog server in a site that does not include all domains. If all domains are represented in the site, or if a global catalog server already exists in the site, then the new global catalog server always has all domains prior to advertising as a global catalog server.

Global Catalog Removal

When you remove the global catalog, the domain controller immediately stops advertising as a global catalog server. The KCC gradually removes the read-only replicas from the domain controller.

Global Catalog Server Management Tasks and Procedures

Table 1.11 shows the tasks and procedures for managing global catalog servers.

Table 1.11   Global Catalog Server Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Identify the global catalog servers in a site.	· Determine whether a domain controller is a global catalog server.	· Active Directory Sites and Services	Monthly.
Identify a site that has no global catalog server.	· Determine whether a site has at least one global catalog server.	· Nltest.exe	Daily to weekly, depending on environment.
Add the global catalog to a domain controller and verify global catalog readiness.	Windows 2000 Server SP2: · Stop the Net Logon service (first global catalog server in the site only). · Configure the domain controller as a global catalog server. · Monitor global catalog replication progress (first global catalog server in the site only). · Verify successful replication to a domain controller. · Verify global catalog readiness. · Restart the Net Logon service, if needed. · Restart the global catalog server and verify global catalog DNS registrations. Windows 2000 Server SP3: · Configure the domain controller as a global catalog server. · Verify global catalog readiness. · Restart the global catalog server and verify global catalog DNS registrations.	· Net stop · Active Directory Sites and Services · Dcdiag.exe · Repadmin.exe · Ldp.exe · DNS · ADSI Edit	As needed.
Remove the global catalog from a domain controller.	· Clear the global catalog setting. · Monitor global catalog removal.	· Active Directory Sites and Services · Event Viewer	As needed.

Identifying Global Catalog Servers in a Site

Maintain a list of those servers that are designated as global catalog servers. Routinely check these servers to ensure that no one has changed the designation. Check other servers to ensure that no one has erroneously designated a global catalog server.

Procedure for Identifying a Global Catalog Server

Use the following procedure to determine whether a domain controller is a global catalog server. The procedure is explained in detail in the linked topic.

· To determine whether a domain controller is a global catalog server, check the properties on the NTDS Settings object of the respective server object.

Identifying a Site That Has No Global Catalog Servers

To quickly identify a site that has no global catalog servers, you can perform one command rather than check each server individually. You can perform this test any time you add a site, or routinely if global catalog servers can potentially be removed inappropriately.

Procedure for Identifying a Site that has No Global Catalog Servers

Use the following procedure to determine whether a site has a global catalog server. The procedure is explained in detail in the linked topic.

· To identify a site that has no global catalog servers, determine whether the site has at least one global catalog server.

Adding the Global Catalog to a Domain Controller and Verifying Readiness

When conditions in a site warrant adding a global catalog server, you can configure a domain controller to be a global catalog server. Selecting the Global catalog setting on the NTDS Settings object prompts the KCC to update the topology. After the topology is updated, then read-only partial domain directory partitions are replicated to the designated domain controller. When replication must occur between sites to create the global catalog, the site link schedule determines when replication can occur.

Minimum hardware requirements for global catalog servers depend upon the numbers of users in the site. Table 1.12 contains guidelines for assessing hardware requirements.

Table 1.12   Global Catalog Hardware Requirements

Users in site	Domain controller
<= 100	One uniprocessor PIII 500, 512 MB.
101 – 500	One uniprocessor PIII 500, 512 MB.
500 – 1,000	One Dual PIII 500, 1 GB.
1,001 – 10,000	Two Quad PIII XEON, 2 GB.
> 10,000 users	One Quad PIII XEON, 2 GB for every 5,000 users.

When configuring a global catalog server, be sure the machine has adequate hard disk space. Use the information in Table 1.13 to determine how much storage to provide for the Active Directory database.

Table 1.13   Global Catalog Storage Requirements for the Active Directory Database

Server	Active Directory database storage requirements
Domain controller	0.4 GB of storage for each 1,000 users.
Global catalog server

For example, in a forest with two 10,000-user domains, all domain controllers need 4 GB of storage. All global catalog servers require 6 GB of storage.

These requirements represent conservative estimates. For a more accurate determination of storage requirements, download and run the Active Directory Sizer Tool (ADSizer.exe). You can download the ADSizer.exe tool from the Active Directory Sizer Tool link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.

Occupancy Levels and Global Catalog Server Readiness

The occupancy level setting on a domain controller determines the criteria for advertising itself as a global catalog server in DNS. If a global catalog server advertises itself before it has synchronized all read-only directory partition replicas, clients can receive incorrect information.

The requirements of the occupancy levels are as follows (each higher level includes all levels below it):

· 0: No occupancy requirement.

· 1: An inbound connection for at least one read-only directory partition in the site of the global catalog server is added to the designated server by the KCC. Event ID 1264 in the Directory Service log signals creation of the inbound connection.

· 2: At least one read-only directory partition in the site is replicated to the global catalog server.

· 3: Inbound connections for all read-only directory partitions in the site are added by the KCC, and at least one is replicated to the server.

· 4: All read-only directory partitions in the site are replicated to the server.

· 5: Inbound connections for all read-only directory partitions in the forest are added by the KCC, and all directory partitions in the site are replicated to the server.

· 6: All directory partitions in the forest are replicated to the server.

Default occupancy levels for domain controllers that are running Windows 2000 Server depend on the Windows 2000 Server service pack release that is installed, as follows:

· Windows 2000 Server SP2 or earlier: default and maximum occupancy level = 4.

· Windows 2000 Server SP3: default and maximum occupancy level = 6.

Exchange 2000 servers use the global catalog exclusively when looking up addresses. Therefore, in addition to causing Active Directory client search problems, the condition of a global catalog server being advertised before it receives all partial replicas can cause Address Book lookup and mail delivery problems for Exchange clients.

The Name Service Provider Interface (NSPI) must be running on a global catalog server to enable MAPI access to Active Directory. To enable NSPI, you must restart the global catalog server after replication of the partial directory partitions is complete.

Verification of Global Catalog Server Readiness

A global catalog is considered ready to serve clients when the following events occur, in this order:

· Occupancy level requirements are met by replicating read-only replicas.

· The isGlobalCatalogReady rootDSE attribute is set to TRUE.

· The Net Logon service on the domain controller has updated DNS with global-catalog-specific SRV resource records.

At this point, the global catalog server is available to respond to requests on ports 3268 and 3269. However, in response to various tests, the local system can indicate that it is a global catalog server as soon as replication requirements are met, but before DNS has been updated. For a global catalog server that is running Windows 2000 Server SP2, you must also consider the replication requirements for the occupancy level. For the first global catalog server in a site, the occupancy level is significant if all domains are not represented in the site.

Global Catalog Readiness in the SP2 Environment

Because the default occupancy level requirement in Windows 2000 Server SP2 is limited to replicating only the domain directory partitions that are available in the local site, a global catalog server in this environment might advertise itself as ready when other domains are not present on the server. For this reason, when adding the first global catalog to a site where all domains in the forest are not represented, you must take steps to ensure that the global catalog server does not advertise itself before all domain directory partitions are present on the server, as follows:

· Prior to configuring the domain controller to be a global catalog server, stop the Net Logon service on the domain controller. If the Net Logon service is not running, then the server cannot update DNS prematurely.

· Monitor replication until all domain directory partitions are replicated to the server.

· Verify successful replication of all domain directory partitions in the forest.

· Restart the domain controller to enable NSPI. Restarting will also start the Net Logon service automatically.

· Verify DNS updates.

Global Catalog Readiness in the SP3 Environment

Because the default occupancy level requirement in Windows 2000 Server SP3 is level 6, a new global catalog server does not advertise itself until all partial domain directory partitions in the forest are replicated to the server. In this case, you do not have to stop the Net Logon service before configuring the domain controller as a global catalog server. However, you do need to restart the domain controller to enable NSPI.

Procedures for Adding the Global Catalog to a Domain Controller and Verifying Global Catalog Readiness

Use the following procedures to add a global catalog server to a domain controller. The procedures are explained in detail in the linked topics. Some procedures are performed only when you are configuring the first global catalog server in the site or only when Windows 2000 Server SP2 is running on the domain controller that you are configuring.

1. Stop the Net Logon service on the domain controller (SP2 only, first global catalog server in the site only).

2. Configure the domain controller as a global catalog server. Setting the Global Catalog check box initiates the process of replicating all domains to the server.

3. Monitor global catalog replication progress (first global catalog server in the site only).

4. Verify successful replication to a domain controller on the global catalog server. Check for inbound replication of all partial domain directory partitions in the forest, to ensure that all domain directory partitions have replicated to the global catalog server.

5. Verify global catalog readiness. This procedure indicates that the replication requirements have been met.

6. Restart the Net Logon service, if needed. If you are adding the first global catalog server in a site to a domain controller that is running Windows 2000 Server SP2 and you stopped the Net Logon service prior to adding the global catalog, then restart the service now.

7. Restart the global catalog server and verify global catalog DNS registrationss by checking DNS for global catalog SRV resource records.

Removing the Global Catalog from a Domain Controller

If the user population of a site decreases to the point where multiple global catalog servers are not required, or if a global catalog server is being replaced with a more powerful machine, then you can remove the global catalog from the domain controller.

The procedure to remove the global catalog is simply to clear the Global Catalog check box on the NTDS Settings object properties page. As soon as you perform this step, the domain controller stops advertising itself as a global catalog server (Net Logon de-registers the global catalog-related records in DNS) and immediately stops accepting LDAP requests over ports 3268 and 3269.

When you remove the global catalog from a domain controller, the KCC begins removing the read-only replicas one at a time by means of an asynchronous process that removes objects gradually over time. Each time the KCC runs (every 15 minutes by default), it attempts the removal of the read-only replica until there are no remaining objects. At an estimated rate of 2000 objects per hour, complete removal of the global catalog from the domain controller can take from several hours to days, depending on the size of the directory.

Procedures for Removing the Global Catalog from a Domain Controller

Use the following procedures to remove the global catalog from a domain controller. The procedures are explained in detail in the linked topics.

1. Clear the Global Catalog setting.

2. Monitor global catalog removal in Event Viewer.

Managing Operations Masters

Operations masters keep the directory functioning properly by performing specific tasks that no other domain controllers are permitted to perform. Because operations masters are critical to the long-term performance of the directory, they must be available to all domain controllers and desktop clients that require their services. Careful placement of your operations masters becomes more important as you add more domains and sites to build your forest.

Operations Master Roles

Three operations master roles exist in each domain:

· The primary domain controller (PDC) emulator. The PDC emulator processes all replication requests from Microsoft Windows NT 4.0 backup domain controllers and processes all password updates for clients that are not running Active Directory–enabled client software.

· The relative identifier (RID) master. The RID master allocates RIDs to all domain controllers to ensure that all security principals have a unique identifier.

· The infrastructure master. The infrastructure master for a given domain maintains a list of the security principals from other domains that are members of groups within its domain.

In addition to the three domain-level operation master roles, two operations master roles exist in each forest:

· The schema master, which governs all changes to the schema.

· The domain naming master, which adds and removes domains to and from the forest.

To perform these functions, the domain controllers hosting these operations master roles must be located in areas where network reliability is high and they need to be consistently available.

Reasons to Move an Operations Master Role

Operations master role holders are placed automatically when the first domain controller in a given domain is created. The three domain-level roles are assigned to the first domain controller created in a domain. The two forest-level roles are assigned to the first domain controller created in a forest.

You might need to move a master operations role to a different domain controller if the service level becomes insufficient, if the domain controller holding the operations master role fails or is decommissioned, or if you make incompatible configuration changes.

_{Insufficient service level}

The PDC emulator is the operations master role that most impacts the performance of a domain controller. For clients that do not run Active Directory client software, the PDC emulator processes requests for password changes, replication, and user authentication. While providing support for these clients, the domain controller continues to perform its normal services, such as authenticating Active Directory–enabled clients. As the network grows, the volume of client requests can increase the workload for the domain controller that hosts the PDC emulator role and its performance can suffer. To solve this problem, you can transfer all or some of the master operation roles to another, more powerful domain controller. You may choose to transfer the role to another domain controller, upgrade the hardware on the original domain controller and then transfer the role back again.

_{Master operations role holder failure}

In the event of a failure, you must decide if you need to relocate the master operations roles to another domain controller or wait for the domain controller to be returned to service. Base that determination on the role that the domain controller hosts and the expected down time.

_{Decommissioning of the domain controller}

Before permanently taking a domain controller offline, transfer any operations master roles that the domain controller holds to another domain controller.

_{Incompatible configuration changes}

Configuration changes to domain controllers or the network topology can result in the need to transfer master operations roles. Except for the infrastructure master, you can assign operations master roles to any domain controller regardless of any other tasks that the domain controller performs. Do not host the infrastructure master role on a domain controller that is also acting as a global catalog server, unless all of the domain controllers in the domain are global catalog servers, or unless only one domain is in the forest. If the domain controller hosting the infrastructure master role is configured to be a global catalog server, you must transfer the infrastructure master role to another domain controller. Changes to the network topology can result in the need to transfer operation master roles in order to keep them in a particular site.

Considerations for Moving Operations Master Roles

You can reassign an operations master role by transfer or, as a last resort, by seizure.

_{Role transfer}

Role transfer is the preferred method to move an operations master role from one domain controller to another. During a role transfer, the two domain controllers replicate to ensure that no information is lost. After the transfer completes, the previous role holder reconfigures itself so that it no longer attempts to perform as the operations master while the new domain controller assumes those duties. This prevents the possibility of duplicate operations masters existing on the network at the same time, which can lead to corruption in the directory.

_{Role seizure}

Seize a role only as a last resort to assign a role to a different domain controller. Use this process only when the previous operations master fails and remains out of service for an extended amount of time. During a role seizure, the domain controller does not verify that replication is updated, so recent changes can be lost. Because the previous role holder is unavailable during the role seizure, it cannot know that a new role holder exists. If the previous role holder comes back online it might still assume that it is the operations master. This can result in duplicate operations master roles on the network, which can lead to corruption of data in the directory and ultimately to the failure of the domain or forest.

To transfer a role to a new domain controller, ensure that the destination domain controller is a direct replication partner of the previous role holder and that replication between them is up to date and functioning properly. This minimizes the time required to complete the role transfer. If replication is sufficiently out of date, the transfer can take a while, but it eventually finishes.

Important

If you must seize an operations master role, never reattach the previous role holder to the network without following the procedures in this guide. Incorrectly reattaching the previous role holder to the network can result in invalid data and corruption of data in the directory.

Guidelines for Role Placement

By improperly placing operations master role holders, you might prevent clients from changing their passwords, or be unable to add domains and new objects, such as users and groups. You might also be unable to make changes to the schema. In addition, name changes might not properly appear within group memberships that are displayed in the user interface.

As your environment changes, you must avoid the problems associated with improperly placed operations master role holders. Eventually, you might need to reassign the roles to other domain controllers.

Although you can assign the forest-level and domain-level operations master roles to any domain controller in the forest and domain respectively, improperly placing the infrastructure master role can cause it to not function properly. Other improper configurations can increase administrative overhead.

Requirements for infrastructure master placement

Do not place the infrastructure master on a domain controller that is also a global catalog server.

The infrastructure master updates the names of security principals from other domains that are added to groups in its own domain. For example, if a user from one domain is a member of a group in a second domain and the user’s name is changed in the first domain, then the second domain is not notified that the user’s name must be updated in the group’s membership list. Because domain controllers in one domain do not replicate security principals to domain controllers in another domain, the second domain never becomes aware of the change. The infrastructure master constantly monitors group memberships, looking for security principals from other domains. If it finds one, it checks with the security principal’s domain to verify that the information is updated. If the information is out of date the infrastructure master performs the update and then replicates the change to the other domain controllers in its domain.

Two exceptions apply to this rule. First, if all the domain controllers are global catalog servers, the domain controller that hosts the infrastructure master role is insignificant because global catalogs do replicate the updated information regardless of the domain to which they belong. Second, if the forest has only one domain, the domain controller that hosts the infrastructure master role is not needed because security principals from other domains do not exist.

Recommendations for role placement

Although you can assign the operations master roles to any domain controller, follow these guidelines to minimize administrative overhead and ensure the performance of Active Directory. If a domain controller that is hosting operation master roles fails, following these guidelines also simplifies the recovery process. Guidelines for role placement include:

· Leave the two forest-level roles on a domain controller in the forest root domain.

· Place the two forest-level roles on a global catalog server.

· Place the three domain-level roles on the same domain controller.

· Do not place the domain-level roles on a global catalog server.

· Place the domain-level roles on a higher performance domain controller.

· Adjust the workload of the operations master role holder, if necessary.

· Choose an additional domain controller as the standby operations master for the forest-level roles and choose an additional domain controller as the standby for the domain-level roles.

_{Forest-level role placement in the forest root domain}

The first domain controller created in the forest is assigned the schema master and domain naming master roles. To ease administration and backup and restore procedures, leave these roles on the original forest root domain controller. Moving the roles to other domain controllers does not improve performance. Separating the roles creates additional administrative overhead when you must identify the standby operations masters and when you implement a backup and restore policy.

Unlike the PDC emulator role, forest-level roles rarely place a significant burden on the domain controller. Keep these roles together to provide easy, predictable management.

_{Forest-level role placement on a global catalog server}

In addition to hosting the schema master and domain naming master roles, the first domain controller created in a forest also hosts the global catalog. In Windows 2000 Server, you must leave the domain naming master on a global catalog server. When the domain naming master creates an object representing a new domain, it uses the global catalog to ensure that no other object has the same name. The domain naming master achieves this consistency by running on a global catalog server, which contains a partial replica of every object in the forest.

_{Domain-level role placement on the same domain controller}

The three domain-level roles are assigned to the first domain controller created in a new domain. Except for the forest root domain, leave the roles at that location. Keep the roles together unless the workload on your operations master justifies the additional management burden of separating the roles.

For the forest root domain, the first domain controller also hosts the two forest-level roles as well as the global catalog. This additional workload requires you to take two precautionary steps to avoid potential problems. First, the domain-level roles must not remain on a global catalog server. In addition, because hosting all five roles on a single domain controller can overload the server and hurt performance, transfer the three domain-level roles to another domain controller.

Because all pre-Active Directory clients submit updates to the PDC emulator, the domain controller holding that role uses a higher number of RIDs. Place the PDC emulator and RID master roles on the same domain controller so these two roles interact more efficiently.

If you must separate the roles, you can still use a single standby operations master for all three roles. However, you must ensure that the standby is a replication partner of all three of the role holders.

Backup and restore procedures also become more complex if you separate the roles. Special care must be taken to restore a domain controller that hosted an operations master role. By hosting the roles on a single computer, you minimize the steps that are required to restore a role holder.

_{Domain-level role absence on a global catalog server}

Do not host the infrastructure master on a domain controller that is acting as a global catalog server. Because it is best to keep the three domain-level roles together, avoid putting any of them on a global catalog server.

_{Domain-level role placement on a higher performance domain controller}

Host the PDC emulator role on a powerful and reliable domain controller to ensure that it is available and capable of handling the workload. Of all the operations master roles, the PDC emulator creates the most overhead on the server that is hosting the role. It has the most intensive daily interaction with other systems on the network. The PDC emulator has the greatest potential to affect daily operations of the directory.

_{Workload adjustment of the operations master role holder}

Domain controllers can become overloaded while attempting to service client requests on the network, manage their own resources, and handle any specialized tasks such as performing the various operations master roles. This is especially true of the domain controller holding the PDC emulator role. Pre‑Active Directory clients and domain controllers running Windows NT 4.0 rely more heavily on the PDC emulator than Active Directory clients and Windows 2000 Server domain controllers. If your networking environment has pre-Active Directory clients and domain controllers, you might need to reduce the workload of the PDC emulator.

If a domain controller begins to indicate that it is overloaded and the performance is affected, you can reconfigure the environment so that some tasks are performed by other, less-used domain controllers. By adjusting the domain controller’s weight in the DNS environment, you can configure the domain controller to receive fewer client requests than other domain controllers on your network. Optionally, you can adjust the domain controller’s priority in the DNS environment so it processes client requests only if other DNS servers are unavailable. With fewer DNS client requests to process, the domain controller can use more resources to perform operations master services for the domain.

_{Standby operations master}

The standby operations master is a domain controller that you identify as the computer that assumes the operations master role if the original computer fails. You do not need to perform any special configuration steps or run any type of setup utilities to make a domain controller a standby operations master. This precautionary planning step helps make your operation more resilient if a problem arises that requires you to reassign a master operations role to a new domain controller.

Ensure that the standby operations master is a direct replication partner of the actual operations master. If the standby operations master domain controller is a direct replication partner of the original operations master, it most likely contains the most recent changes to the domain. This reduces the time required to transfer the role to the standby operations master and, in the case of a failure, reduces the chances of losing information. Even if replication is not totally complete, only few outstanding updates exist. Those outstanding updates can be replicated by a normal replication cycle rather than requiring a full synchronization, which replicates all of the account information in the partition. To guarantee that the two domain controllers are replication partners, you must manually create a connection object between them. Although creating manual connection objects is not generally recommended, in this one case it is necessary because it is so important that these two domain controllers be replication partners.

If you must reassign the domain-level operations master roles to the standby operations master, do not place the infrastructure master role on a global catalog server.

Ramifications of Role Seizure

If a role is seized, the new role holder is configured to host the operations master role with the assumption that you do not intend to return the previous role holder to service. Use role seizure only when the previous role holder is not available and you need the operations master role to keep the directory functioning. Because the previous role holder is not available during a seizure, you cannot reconfigure the previous role holder and inform it that another domain controller is now hosting the operations master role.

If the previous role holder comes back online, its behavior depends on your current service pack level. If you are running Windows 2000 Server Service Pack 2 (SP2) or earlier, the domain controller waits for one replication cycle while it attempts to verify the current role holder. If the previous role holder receives data that indicates that another domain controller is performing the operations master role, it reconfigures itself so that it no longer hosts the operations master role and Active Directory functions properly. If for any reason replication fails, it does not receive any replicated data indicating that a new operations master exists. Whether or not replication actually occurs, after one replication cycle it assumes that the data it has is correct. It leaves itself configured as the current operations master and attempts to resume its duties as the operations master role holder. This results in duplicate operations masters on the network. As shown in Table 1.14, this can cause serious problems in the directory.

If you are running Windows 2000 Server Service Pack 3 (SP3), the previous role holder waits for a full replication cycle to complete successfully before it resumes the role of operations master. By waiting for a full replication cycle, it can see if another operations master exists before it brings itself back online. If the previous role holder detects that another operations master exists, it reconfigures itself so that it no longer hosts the roles in question.

To reduce risk, perform a role seizure only if the missing operations master role unacceptably affects performance of the directory. Calculate the effect by comparing the impact of the missing service provided by the operations master to the amount of work that is needed to bring the previous role holder safely back online after you perform the role seizure.

Active Directory continues to function when the operations master roles are not available. If the role holder is only offline for a short period, you might not need to seize the role to a new domain controller. Remember that returning an operation master to service after the role is seized can have dire consequences if it is not done properly.

Table 1.14   Operations Master Role Functionality Risk Assessment

Operations Master Role	Consequences if Role is Unavailable	Risk of Improper Restoration	Recommendation for Returning to Service After Seizure
Schema master	You cannot make changes to the schema.	Conflicting changes can be introduced to the schema if both schema masters attempt to modify the schema at the same time. This can result in a fragmented schema.	Not recommended. Can lead to a corrupted forest and require rebuilding the entire forest.
Domain naming master	You cannot add or remove domains from the forest.	You cannot add or remove domains or clean-up metadata. Domains might appear as though they are still in the forest even though they are not.	Not recommended. Can require rebuilding domains.
PDC emulator	You cannot change passwords on pre-Active Directory clients. No replication to Windows NT 4.0 backup domain controllers.	Password validation can randomly pass or fail. Password changes take much longer to replicate throughout the domain.	Allowed. User authentication can be erratic for a time, but no permanent damage occurs.
Infrastructure master	Delays displaying updated group membership lists in the user interface when you move users from one group to another.	Displays incorrect user names in group membership lists in the user interface after you move users from one group to another.	Allowed. May impact the performance of the domain controller hosting the role, but no damage occurs to the directory.
RID master	Eventually, domain controllers cannot create new directory objects as each of their individual RID pools is depleted.	Duplicate RID pools can be allocated to domain controllers, resulting in data corruption in the directory. This can lead to security risks and unauthorized access.	Not recommended. Can lead to data corruption that can require rebuilding the domain.

Operations Master Role Management Tasks and Procedures

Table 1.15 shows the tasks and procedures for managing operations master roles.

Table 1.15   Operations Master Role Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Designate operations master roles.	· Verify successful replication to a domain controller. · Determine whether a domain controller is a global catalog server. · Transfer the forest-level operations master roles. · Transfer the domain-level operations master roles. · View the current operations master role holders.	· Repadmin.exe · Active Directory Sites and Services · Active Directory Domains and Trusts · Active Directory Users and Computers · Ntdsutil.exe	As needed
Reduce the workload on the PDC emulator.	· Change the weight for DNS SRV records in the registry. · Change the priority for DNS SRV records in the registry.	· Regedit.exe	As needed
Decommission a role holder.	· Verify successful replication to a domain controller. · Determine whether a domain controller is a global catalog server. · Transfer the forest-level operations master roles. · Transfer the domain-level operations master roles. · View the current operations master role holders.	· Repadmin.exe · Active Directory Sites and Services · Active Directory Domains and Trusts · Active Directory Users and Computers · Ntdsutil.exe	As needed
Seize operations master roles.	· Verify that a complete end-to-end replication cycle had occurred. · Verify successful replication to a domain controller. · Seize the operations master role. · View the current operations master role holders.	· Ntdsutil.exe	As needed
Choose a standby operations master.	· Determine whether a domain controller is a global catalog server. · Create a connection object.	· Active Directory Sites and Services	As needed

Designating Operations Master Roles

When you create a new domain, the Active Directory Installation Wizard automatically assigns all of the domain-level operations master roles to the first domain controller that is created in that domain. When you create a new forest, the wizard also assigns the two forest-level operations master roles to the first domain controller. After the domain is created and functioning, you might transfer various operations master roles to different domain controllers to optimize performance and simplify administration.

Transferring the forest-level and domain-level operations master roles is performed as needed and governed by the guidelines for placing operations master roles. Before you transfer an operations master role, use Repadmin.exe with the /showreps option to ensure that replication between the current role holder and the domain controller assuming the role is updated.

In addition, you must determine if the domain controller that you intend to assume an operations master role is a global catalog server. The domain naming master, a forest-level role, must also host the global catalog. However, the infrastructure master for each domain must not host the global catalog.

Do not change the global catalog configuration on the domain controller that you intend to assume an operations master role unless your IT management authorizes that change. Changing the global catalog configuration can cause changes that can take days to complete and the domain controller might not be available during that period. Instead, transfer the operations master roles to a different domain controller that is already properly configured.

Procedures for Designating Operations Master Roles

Procedures are explained in detail in the linked topics.

1. Verify successful replication to a domain controller.

2. Determine whether a domain controller is a global catalog server.

3. Transfer the forest-level operations master roles.

4. Transfer the domain-level operations master roles.

5. View the current operations master role holders.

Reducing the Workload on the PDC Emulator

You can configure a domain controller so that DNS sends the majority of client requests to other domain controllers. Reducing the number of client requests helps reduce the workload on a domain controller, giving it more time to function as an operations master, and is especially important for the PDC emulator. Of all the operations master roles, the PDC role has the highest impact on the domain controller hosting that role. You might need to take steps to keep that domain controller from becoming overloaded.

To receive information from the domain, a client uses DNS to locate a domain controller and then sends the request to that domain controller. By default, DNS performs rudimentary load balancing and randomizes the distribution of client requests so they are not always sent to the same domain controller. If too many client requests are sent to a domain controller while it attempts to perform other duties, such as those of the PDC emulator, it can become overloaded, which has a negative impact on performance. To reduce the number of client requests that are processed by the PDC emulator, you can adjust its weight in the DNS environment or you can adjust its priority in the DNS environment.

DNS Weight Registry Setting

Adjusting the weight of a domain controller to less than other domain controllers reduces the number of clients that DNS refers to that domain controller. The default weight for all domain controllers is 100. By reducing this value, DNS refers clients to a domain controller less frequently based on the proportion of this value to the value of other domain controllers. For example, to configure the system so that the domain controller hosting the PDC emulator role receives requests only half as many times as the other domain controllers, configure the weight of the domain controller hosting the PDC emulator role to be 50. DNS determines the weight ratio for that domain controller to be 50/100 (50 for that domain controller and 100 for the other domain controllers). After you reduce this ratio to 1/2, DNS refers clients to the other domain controllers twice as often as it refers to the domain controller with the reduced weight setting. By reducing client referrals, the domain controller receives fewer client requests and has more resources for other tasks, such as performing the role of PDC emulator.

DNS Priority Registry Setting

Adjusting the priority of the domain controller also reduces the number of client referrals. However, rather than reducing it proportionally to the other domain controllers, changing the priority causes DNS to stop referring all clients to this domain controller unless all domain controllers with a lower priority setting are unavailable.

To configure the PDC emulator in this manner, use Regedit.exe to modify the ldapsrvpriority or ldapsrvweight registry entries.

Procedures for Reducing the Number of Client Requests Processed by the PDC Emulator

Procedures are explained in detail in the linked topics.

1. Change the weight for DNS SRV records in the registry.

2. Change the priority for DNS SRV records in the registry.

Decommissioning a Role Holder

When you use the Active Directory Installation Wizard to decommission a domain controller that currently hosts one or more operations master roles, the wizard reassigns the roles to a different domain controller. When the wizard is run, it determines whether the domain controller currently hosts any operations master roles. If it detects any operations master roles, it queries the directory for other eligible domain controllers and transfers the roles to a new domain controller. A domain controller is eligible to host the domain-level roles if it is a member of the same domain. A domain controller is eligible to host a forest-level role if it is a member of the same forest.

You cannot control which domain controller the wizard chooses and the wizard does not indicate which domain controller receives the roles. Because of this behavior, it is best to transfer the roles prior to running the wizard. That way you can control role placement and can transfer the roles according to the recommendations discussed earlier in this guide.

Transfer to the Operations Master Standby

Transfer the operations master roles to the standby operations master. By following the recommendations for operations master role placement, the standby operations master is a direct replication partner and is ready to assume the roles. Remember to designate a new standby for the domain controller that assumes the roles.

Transfer when No Standby Operations Master is Ready

If you do not follow the recommendations for role placement and you have not designated a standby operations master, you must properly prepare a domain controller to which you intend to transfer the operations master roles. Preparing the future role holder is the same process as preparing a standby operations master. You must manually create a connection object to ensure that it is a replication partner with the current role holder and that replication between the two domain controllers is updated. To determine whether the standby domain controller received the latest replicated updates from the current operations master, use Repadmin.exe with the /showreps option.

In addition, you must determine whether the domain controller intended to assume an operations master role is a global catalog server. The domain naming master, a forest-level role, must also host the global catalog. However, the infrastructure master for each domain must not host the global catalog.

Do not change the global catalog configuration on the domain controller that you intend to assume an operations master role unless your IT management authorizes that change. Changing the global catalog configuration can cause changes that can take days to complete and the domain controller might not be available during that period. Instead, transfer the operations master roles to a different domain controller that is already properly configured.

Procedures for Decommissioning a Role Holder

Procedures are explained in detail in the linked topics.

1. Verify successful replication to a domain controller.

2. Determine whether a domain controller is a global catalog server.

3. Transfer the forest-level operations master roles.

4. Transfer the domain-level operations master roles.

5. View the current operations master role holders.

Seizing Operations Master Roles

Seize an operations master role only as a last resort. If at all possible, transfer an operations master role to a new domain controller instead. Seize an operations master role only if the current role owner is offline and is unlikely to return to service.

Role seizure is the act of assigning an operations master role to a new domain controller without the cooperation of the current role holder (usually because it is offline due to a hardware failure). During role seizure, a new domain controller assumes the operations master role without communicating with the current role holder.

Role seizure can create two conditions that can cause problems in the directory. First, the new role holder starts performing its duties based on the data located in its current directory partition. The new role holder might not receive changes that were made to the previous role holder before it went offline if replication did not complete prior to the time when the original role holder went offline. This can cause data loss or data inconsistency into the directory database.

To minimize the risk of losing data to incomplete replication, do not perform a role seizure until enough time has passed to complete at least one complete end-to-end replication cycle across your network. Allowing enough time for complete end-to-end replication ensures that the domain controller that assumes the role is as up-to-date as possible.

Second, the original role holder is not informed that it is no longer the operations master role holder, which is not a problem if the original role holder stays offline. However, if it comes back online (for example, if the hardware is repaired or the server is restored from a backup), it might try to perform the operations master role that it previously owned. This can result in two domain controllers performing the same operations master role simultaneously. Depending on the role in question and whether your environment runs Windows 2000 Server SP2 or Windows 2000 Server SP3, this can disrupt the directory service. For example, a RID master might reallocate a duplicate RID pool resulting in corruption of data in the directory. The severity of duplicate operations master roles varies from no visible effect to the need to rebuild the entire forest. For more information about the risks of returning an operations master to service after the role is seized to another domain controller, see “Ramifications of Role Seizure” earlier in this guide.

If you are seizing a role and you have not designated another domain controller as the standby operations master, you can use Repadmin.exe with the /showreps option to identify a domain controller that has the most recent updates from the current role holder. Seize the operations master role to that domain controller to minimize the impact of the role seizure.

Procedures for Seizing Operations Master Roles

Procedures are explained in detail in the linked topics.

1. Verify that a complete end-to-end replication cycle has occurred. During the design process, you calculated the maximum end-to-end replication latency. The maximum end-to-end replication latency is the maximum amount of time it should take for replication to take place between the two domain controllers in your enterprise that are farthest from each other based on the topology of your network. If you verify that replication is functioning properly and wait this amount of time without making any additional changes to the directory then you can assume that all changes have been replicated and the domain controller is up to date.

2. Verify successful replication to a domain controller (the domain controller that will be seizing the role).

3. Seize the operations master role.

4. View the current operations master role holders.

Choosing a Standby Operations Master

A single domain controller can act as the standby operations master for all of the operations master roles in a domain, or you can designate a separate standby for each operations master role. Following the recommendations, it is best to select one standby for the forest-level roles and another standby in each domain that can be used to host the three domain-level roles if their host fails.

No utilities or special steps are required to designate a domain controller as a standby operations master. However, the current operations master and the standby should be well connected. This means that the network connection between them must support at least 10 megabit transmission rate and be available at all times. In addition, configure the current role holder and the standby as direct replication partners by manually creating a connection object between them.

Configuring a replication partner can save some time if you must reassign any operations master roles to the standby operations master. Before transferring a role from the current role holder to the standby operations master, ensure that replication between the two computers is functioning properly. Because they are replication partners, the new operations master is as updated as the original operations master, thus reducing the time required for the transfer operation. To determine whether the standby domain controller received the latest replicated updates from the current operations master, use Repadmin.exe with the /showreps option.

During role transfer, the two domain controllers exchange any unreplicated information to ensure that no transactions are lost. If the two domain controllers are not direct replication partners, a substantial amount of information might need to be replicated before the domain controllers completely synchronize with each other. The role transfer requires extra time to replicate the outstanding transactions. If the two domain controllers are direct replication partners, fewer outstanding transactions exist and the role transfer operation completes sooner.

Designating a domain controller as a standby also minimizes the risk of role seizure. By making the operations master and the standby direct replication partners, you reduce the chance of data loss in the event of a role seizure, thereby reducing the chances of introducing corruption into the directory.

When you designate a domain controller as the standby, follow all recommendations that are discussed in “Guidelines for Role Placement” earlier in this guide. To designate a standby for the forest-level roles, choose a global catalog server so it can interact more efficiently with the domain naming master. To designate a standby for the domain-level roles, ensure that the domain controller is not a global catalog server so that the infrastructure master continues to function properly if you must transfer the roles.

Manually create a connection object between the operations master and the designated standby operations master to ensure that replication occurs between the two domain controllers.

Procedures for Choosing a Standby Operations Master

Procedures are explained in detail in the linked topics.

1. Determine whether a domain controller is a global catalog server.

2. Create a connection object.

Managing the Database

Active Directory is stored in the Ntds.dit database file. In addition to this file, the directory uses log files, which store transactions prior to committing them to the database file. For best performance, store the log files and the database on separate hard drives.

The directory database is a self-maintained system. Other than regular backup, the directory database requires no daily maintenance during ordinary operation. However, you might need to manage the following conditions:

· Low disk space: Monitor free disk space on the partition or partitions that store the directory database and logs. Provide warnings at the following logical-disk-space thresholds:

· Ntds.dit partition: The greater of 20 percent of the Ntds.dit file size or 500 megabytes (MB).

· Log file partition: The greater of 20 percent of the combined log files size or 500 MB.

· Ntds.dit and logs on the same volume: The greater of 1 gigabyte (GB) or 20 percent of the combined Ntds.dit and log files sizes.

Note

If you also set an alert threshold, divide the above warning thresholds in half.

· Database size: During ordinary operation, the database removes expired tombstones and defragments (consolidates) white space. This automatic online defragmentation redistributes and retains white space for use by the database. The following conditions might warrant taking steps to regulate database size manually:

· Temporary backlog of expired tombstones following bulk deletions: Large-scale deletions can temporarily increase the database file size if tombstones expire in larger numbers than garbage collection can remove in one cycle (5,000 tombstones per cycle). After objects are deleted, their tombstones are stored in the directory for 60 days by default and cannot be removed prior to that time. However, after the tombstone lifetime expires, you can speed removal of the tombstone backlog by temporarily decreasing the default garbage collection period (12 hours).

· Increased white space due to large-scale deletions: If data is decreased significantly, such as when the global catalog is removed from a domain controller, white space is not automatically returned to the file system. Although this condition does not affect database operation, it does result in a larger file size. You can use offline defragmentation to decrease the size of the database file by returning white space from the database file to the file system.

· Hardware upgrade or failure: If you need to upgrade or replace the disk on which the database or log files are stored, move the files to a different location, either permanently or temporarily.

For information about monitoring the database and log file partitions for low disk space, see “Monitoring Active Directory” earlier in this guide.

General Guidelines for Directory Database Management

For all database management tasks, follow these guidelines:

· Prior to performing any procedures that affect the directory database, be sure that you have a current system state backup. For information about performing system state backup, see “Active Directory Backup and Restore” earlier in this guide.

· To manage the database file itself, you must take the domain controller offline by restarting in Directory Services Restore Mode, and then use Ntdsutil.exe to manage the file.

u To start a domain controller in Directory Services Restore Mode, you must log on to the domain controller as the local Administrator. To remotely manage the database, you can use Terminal Services Client to restart the domain controller in Directory Services Restore Mode.

· NTFS Disk Compression is not supported for the database and log files.

Directory Database Management Tasks and Procedures

Table 1.16 shows the tasks and the procedures for managing the database.

Table 1.16   Directory Database Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Relocate directory database files.	· Determine the databasesize and location (online or offline). · Compare size of the directory database files to the volume size. · Back up system state. · Restart the domain controller in Directory Services Restore Mode (locally or remotely). · Move the directory database files. · Move the directory database files to a local drive. · Copy the directory database files to a remote share and back. · If the path has changed, back up system state.	· dir · Backup Wizard · Terminal Services Client · Notepad · Ntdsutil.exe · Windows Explorer	As needed.
Return unused disk space from the directory database to the file system.	· Change the garbage collection logging level. · Back up system state. · Restart the domain controller in Directory Services Restore Mode (locally or remotely). · Compact the directory database offline (offline defragmentation). · Check database integrity. · If no errors, perform standard semantic database analysis. · If errors, perform semantic database analysis with fixup. · If errors, perform database recovery.	· Registry editor · Backup Wizard · net use, del, copy · Ntdsutil.exe	As needed.
Speed removal of an expired-tombstone backlog.	· Change (decrease) the garbage collection period. · Change (increase) the garbage collection logging level. · Verify removal of tombstones in the event log. · Change (return to normal) the garbage collection period. · Change (return to normal) the garbage collection logging level. · Compact the directory database offline (offline defragmentation), if needed.	· ADSI Edit · Registry editor · Event Viewer · Ntdsutil.exe	As needed.

Relocating Directory Database Files

The following conditions require moving database files:

· Hardware maintenance: If the physical disk on which the database or log files are stored requires upgrading or maintenance, the database files must be moved, either temporarily or permanently.

· Low disk space: When free disk space is low on the logical drive that stores the database file (Ntds.dit), the log files, or both, first verify that no other files are causing the problem. If the database file or log files are the cause of the growth, then provide more disk space by taking one of the following actions:

· Expand the partition on the disk that currently stores the database file, the log files, or both. This procedure does not change the path to the files and does not require updating the registry.

· Use Ntdsutil.exe to move the database file, the log files, or both to a larger existing partition. Moving files to a different partition changes the path to the files and therefore requires updating the registry. Ntdsutil.exe automatically updates the registry when you use it to move database files.

Path Considerations

If the path to the database file or log files changes as a result of moving the files, be sure that you:

· Use Ntdsutil.exe to move the files (rather than copying them) so that the registry is updated with the new path. Even if you are moving the files only temporarily, use Ntdsutil.exe to move files locally so that the registry is always current.

· Perform a system state backup as soon as the move is complete so that the restore procedure uses the correct path.

· Verify that the correct permissions are applied on the destination folder following the move. Revise permissions to those that are required to protect the database files, if needed.

SYSVOL Considerations

If you replace or reconfigure a drive that stores the SYSVOL folder, you must first move the SYSVOL folder manually. For information about moving SYSVOL manually, see “Managing SYSVOL” later in this guide.

Procedures for Relocating Directory Database Files

Use the following procedures to move or copy the database file, the log files, or both. Procedures are explained in detail in the linked topics.

1. Determine the location and size of the directory database files. Use the database size to prepare a destination location of the appropriate size. Track the respective file sizes during the move to ensure that you successfully move the correct files. Be sure to use the same method to check file sizes when you compare them. The size is reported differently, depending on whether the domain controller is online or offline, as follows:

· Determine the database size and location online. This size is reported in bytes.

· Determine the database size and location offline. This size is reported in megabytes (MB). Use this method if the domain controller is already started in Directory Services Restore Mode.

2. Compare the size of the directory database files to the volume size. Before moving any files in response to low disk space, verify that no other files on the volume are responsible for the condition of low disk space.

3. Back up system state. System state includes the database file and log files as well as SYSVOL and NETLOGON shared folders, among other things. Always ensure that you have a current backup prior to moving database files.

4. Restart the domain controller in Directory Services Restore Mode, as follows:

· If you are logged on to the domain controller console, locally restart the domain controller in Directory Services Restore Mode.

· If you are using Terminal Services for remote administration, modify the Boot.ini file on the remote server so that you can remotely restart the domain controller in Directory Services Restore Mode.

5. Move the database file, the log files, or both. Move the files to a temporary destination if you need to reformat the original location, or to a permanent location if you have additional disk space. Moving the files can be performed locally by using Ntdsutil.exe or remotely (temporarily) by using a file copy, as follows:

· Move the directory database files to a local drive.

· Copy the directory database files to a remote share and back. When copying any database files off the local computer, always copy both the database file and the log files.

6. If the path to the database or log files has changed, back up system state so that the restore procedure has the correct information.

Returning Unused Disk Space from the Directory Database to the File System

During ordinary operation, the white space in the directory database file becomes fragmented. Each time garbage collection runs (every 12 hours by default), white space is automatically defragmented online to optimize its use within the database file. The unused disk space is thereby maintained for the database; it is not returned to the file system.

Only offline defragmentation can return unused disk space from the directory database to the file system. When database contents have decreased considerably through a bulk deletion (for example, you remove the global catalog from a domain controller), if the size of the database backup is significantly increased due to the white space, use offline defragmentation to reduce the size of the Ntds.dit file.

You can determine how much free disk space is recoverable from the Ntds.dit file by setting the Garbage Collection logging level in the registry. Changing the Garbage Collection logging level from the default value of 0 to a value of 1 results in event ID 1646 being logged in the Directory Service log. This event describes the total amount of disk space used by the database file as well as the amount of free disk space that is recoverable from the Ntds.dit file through offline defragmentation.

At Garbage Collection logging level 0, only critical events and error events are logged in the Directory Service log. At level 1, high-level events are logged as well. Events can include one message for each major task that is performed by the service. At level 1, the following events are logged for garbage collection:

· 700 and 701: report when online defragmentation begins and ends, respectively.

· 1646: reports the amount of free space available in the database out of the amount of allocated space.

Caution

Setting the value of entries in the Diagnostics subkey to greater than 3 can degrade server performance and is not recommended.

Following offline defragmentation, perform a database integrity check. The integrity command in Ntdsutil.exe detects binary-level database corruption by reading every byte in the database file. The process ensures that the correct headers exist in the database itself and that all of the tables are functioning and consistent. Therefore, depending upon the size of your Ntds.dit file and the domain controller hardware, the process might take considerable time. In testing environments, the speed of 2 GB per hour is considered to be typical. When you run the command, an online graph displays the percentage completed.

Procedures for Performing Offline Defragmentation

Use the following procedures to perform offline defragmentation. Procedures are explained in detail in the linked topics.

1. Change the garbage collection logging level to 1. Check the Directory Service event log for event ID 1646, which reports the amount of disk space that you can recover by performing offline defragmentation.

2. Back up system state. System state includes the database file and database log files as well as SYSVOL, NETLOGON, and the registry, among other things. Always ensure that a current backup exists prior to defragmenting database files.

3. Take the domain controller offline, as follows:

· If you are logged on to the domain controller locally, restart the domain controller in Directory Services Restore Mode.

· If you are using Terminal Services for remote administration, you can remotely restart the domain controller in Directory Services Restore Mode after modifying the Boot.ini file on the remote server.

4. Compact the directory database file (offline defragmentation). As part of the offline defragmentation procedure, check directory database integrity.

5. If database integrity check fails, perform semantic database analysis with fixup.

Speeding Removal of an Expired-Tombstone Backlog

An object that is deleted from Active Directory is stored as a tombstone, which represents the deleted object in the directory so that the deletion is replicated. Tombstones remain in the directory for a default period of 60 days from the time of deletion, at which point they expire and are permanently removed by garbage collection.

Note

Tombstones cannot be removed prior to expiration of the tombstone lifetime.

Although tombstones use less space than the full object, they can affect the size of the database temporarily following large bulk deletions. A maximum of 5,000 expired tombstones can be deleted at one time. If the number of expired tombstones exceeds 5,000, more than one garbage collection interval is required to clear the backlog. During the backlog, tombstones that are no longer needed are retained, consuming database space.

Increased Rate of Tombstone Removal

The default garbage collection period is 12 hours. Temporarily decreasing the garbage collection period (for example, to 1 hour) can help speed the removal of expired tombstones. However, setting this period too low can also cause slow performance, so be sure to return the value to the original setting as soon as the backlog is cleared. To reduce database size by returning the white space left by the removed tombstones to the file system, perform offline defragmentation after the backlog is cleared.

Logging of Tombstone Removal

The default logging level for garbage collection is 0. At this level, only errors are reported. When garbage collection logging is set to 3, event ID 1006 reports the number of expired tombstones removed during each garbage collection cycle.

If you want to track removal of expired tombstones, increase the logging level to 3 and decrease the garbage collection period until the backlog is cleared, and then return the logging level and the garbage collection period to normal.

Procedures for Regulating Directory Database Growth Caused by Tombstones

Use the following procedures to manage removal of tombstones following bulk deletions.

1. Change the garbage collection period to a lower interval. Decreasing the interval between garbage collections helps the system eliminate the tombstone backlog more quickly.

2. Change the garbage collection logging level to 3. Increasing the logging level to 3 causes an event that reports the number of tombstones removed each time garbage collection occurs.

3. Verify removal of tombstones in the event log. Check the Directory Service event log for NTDS event ID 1006, which reports the number of expired tombstones removed. When this event indicates that the number of tombstones removed is less than 5,000, the backlog has been cleared.

4. Change the garbage collection period. When the event ID 1006 reports a number of removed tombstones less than 5,000, you can return the interval between garbage collections to the normal level.

5. Change the garbage collection logging level, if needed. If you no longer want informational events logged for garbage collection, return the logging level to 0.

6. Compact the directory database file (offline defragmentation), if needed. Clearing the backlog does not remove the white space created by the tombstones. Only offline defragmentation returns unused disk space to the file system.

Managing SYSVOL

The Windows 2000 Server System Volume (SYSVOL) is a collection of folders and reparse points in the file systems that exist on each domain controller in a domain. SYSVOL provides a standard location to store Group Policy objects (GPOs) and scripts so that the File Replication service (FRS) can distribute them to other domain controllers and member computers in a domain.

FRS monitors SYSVOL and if a change occurs to any file stored on SYSVOL, then FRS automatically replicates the changed file to the SYSVOL folders on the other domain controllers in the domain.

Computers that run Windows 2000 Server obtain GPOs, logon, logoff, startup, and shutdown scripts from the SYSVOL shared folder. Windows NT 4.0–based domain controllers and Windows-based clients that do not run Active Directory client software obtain GPOs and scripts from the NETLOGON shared folder.

During the installation of Active Directory, the folders and reparse points are automatically created in the %SystemRoot%/SYSVOL folder. FRS automatically replicates any files or GPOs that are written to these folders to the other domain controllers in the domain, to ensure that they are available and ready to be used when a user logs on to the domain.

The day-to-day operation of SYSVOL is an automated process that does not require any human intervention other than watching for alerts from the monitoring system. Occasionally, you might perform some system maintenance as you change your network. The procedures you might perform include:

· Relocating SYSVOL

· Relocating the Staging Area

· Changing the size of the Staging Area

These procedures involve moving SYSVOL or portions of SYSVOL to alternate locations. You might perform these procedures to maintain capacity and performance of SYSVOL, for hardware maintenance, or for data organization.

_Capacity

Depending upon the configuration of your network, SYSVOL can require much disk space to function properly. During the initial deployment, SYSVOL might be allocated adequate disk space to function. However, as your network grows, the required capacity can exceed the available disk space.

Note

If you receive indications that disk space is low, determine if the cause is inadequate physical space on the disk, or a registry setting that allocates inadequate disk space to SYSVOL. By modifying a setting in the registry, you can allocate more disk space to SYSVOL rather than relocating SYSVOL or the Staging Area. Increasing the space allocation in the registry is much faster and easier than relocation. For more information about managing disk space, see “Maintaining Sufficient Disk Space” later in this section.

_Performance

Any changes made to SYSVOL are automatically replicated to the other domain controllers in the domain. If the files stored in SYSVOL change frequently, the replication increases the input and output for the volume where SYSVOL is located. If the volume is also host to other system files, such as the directory database or the pagefile, then the increased input and output for the volume can impact the performance of the server.

_{Hardware Maintenance}

System maintenance, such as removal of a disk drive, can require you to relocate SYSVOL. Even if the maintenance occurs on a different disk drive, verify that that maintenance does not affect the system volume. Logical drive letters can change after you add and remove disks. FRS locates SYSVOL by using pointers stored in the directory and the registry. If drive letters change after you add or remove disk drives, be aware that these pointers are not automatically updated.

_{Data Organization}

Some organizations prefer to control where specific data is stored for organizational purposes and established backup and restore policies.

Guidelines for Managing SYSVOL

To manage SYSVOL, ensure that FRS properly replicates the SYSVOL data, and provide enough space to store SYSVOL. Implement a monitoring system that can detect low disk space and potential FRS disruptions so that you can address those issues before the system stops replicating. For more information about monitoring SYSVOL, see “Monitoring Active Directory” in this guide.

Disk space maintenance

SYSVOL stores and replicates GPOs, Distributed File System (DFS) information, and scripts. As the network grows, SYSVOL can begin to require substantial storage space. Although you do plan for storage requirements for SYSVOL during the planning stages of deployment, you might need to adjust the storage requirements after you deploy additional domain controllers due to network growth and the way in which FRS replicates files.

FRS replicates files by making a temporary copy of the files in a Staging Area folder and then sending the copies to replication partners. This method avoids problems that locked files can cause while replication occurs. Because FRS replicates copies of the files, the original files remain available for user access during replication. However, this method requires making a copy of every file prior to replication. Based on the size and number of files involved, a substantial amount of disk space might be required for temporary storage.

When the Staging Area folder runs out of disk space, FRS behaves differently depending on the version of Windows 2000 that is running. If Windows 2000 Server Service Pack 2 (SP2) or earlier is running, then the system will stop replicating until space is made available. If Windows 2000 Server Service Pack 3 (SP3) is running, then FRS will detect when it is about to run out of disk space and start removing the least recently used files to provide more space. Although this prevents the system from halting replication, it does increase input and output for the server’s disk and can impact performance. For more information about the changes to FRS from Windows 2000 Server SP2 to Windows 2000 Server SP3, see KB article Q321557 in the Microsoft Knowledge Base. To view the Microsoft Knowledge Base, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Both FRS and DFS use the Staging Area folder. To maintain sufficient disk space for SYSVOL, estimate the amount of space that DFS uses as well as the space that FRS uses. For more information about DFS, see “Distributed File System” in the Distributed Systems Guide of the Windows 2000 Server Resource Kit.

Because the Staging Area folder holds files from all replication partners, you must consider traffic to and from all partners when you estimate the disk space requirements for the Staging Area folder on each computer.

If replication must occur between domain controllers that are located in different sites, remember that FRS uses the same connection objects as Active Directory. You can configure those connection objects so that replication can occur only during certain times of the day. Each connection object has an associated schedule that dictates what hours of the day the connection is available for replication. Allocate enough time in the schedule for all Active Directory replication and all FRS replication to occur. If FRS does not complete all outstanding replication requests when the schedule makes the connection available, it will hold the remaining unreplicated files until the next time the connection becomes available. Over time, this backlog of unreplicated files can grow to consume an enormous amount of disk space.

Additional SYSVOL recommendations

You can preserve Staging Area and bandwidth usage by following these best practices:

· Run Windows 2000 SP2 on all domain controllers that run FRS. Install Windows 2000 SP3 as soon as possible.

· Always keep FRS service running, especially when you make bulk changes to FRS-replicated files or files outside the tree on the same drive.

· Do not run anti-virus software against FRS-replicated directories.

· Do not enable File System Group Policy on any FRS-replicated tree.

· Watch for inconsistent directories. Duplicate folders that appear in the FRS replication tree on multiple domain controllers can cause inconsistent directories. Although this is not a critical problem, it can result in unanticipated behavior, such as changes appearing to be lost. If this occurs, examine the files in these directories to determine which directory is the proper version and then delete the duplicated directories from the tree.

· Do not leave files open for extended amounts of time. FRS cannot replicate a file while it is open. Avoid using elements in scripts that cause a file to be open for an extended amount of time, such as a script that waits for user input before proceeding. If the user is not present when the script runs, the file can remain open and cannot be replicated until the script terminates.

· Do not attempt to relocate SYSVOL or the Staging Area if the FRS environment on your network is unstable and you are having problems with system volumes becoming unsynchronized among replication partners. Troubleshoot the FRS problems and ensure that the environment is stable before attempting any relocation operations. During all relocation operations except authoritative restore, FRS rebuilds the SYSVOL content by replicating data from its replication partners. If FRS is not functioning properly on the partners, their SYSVOL data may be invalid. This can result in invalid SYSVOL data in the new location. The relocation operation can also fail because FRS cannot replicate the necessary data from the domain controller’s replication partners.

SYSVOL and Staging Area relocation

Deployment is the best time to determine the location of SYSVOL. Consider performance and disk capacity to determine the best location for the SYSVOL folders. During the Active Directory installation, you must specify the location of the SYSVOL folders. After installation, you might need to relocate SYSVOL or the Staging Area folder.

_{Relocating only the Staging Area}

Although SYSVOL contains many folders, the Staging Area requires the most capacity because it is used for replication. You can leave SYSVOL in its original location and relocate only the Staging Area.

_{Relocating SYSVOL and the Staging Area}

You can relocate the entire SYSVOL folder and its associated subtrees, including the Staging Area.

You can relocate SYSVOL by removing and reinstalling Active Directory on the domain controller or by manually recreating SYSVOL at a new location.

Active Directory removal and reinstallation

To relocate SYSVOL, removing and reinstalling Active Directory is far easier and more reliable than manually recreating SYSVOL at a new location, but it can also be impractical. To relocate SYSVOL by using this method, you use the Active Directory Installation Wizard to remove Active Directory from the domain controller then use it again to reinstall Active Directory on the same domain controller. During the reinstallation, provide the new location for SYSVOL. The replication process populates the folders with the appropriate files from another domain controller. This method might not be practical to use because having a large number of objects in your directory increases the required time for reinstallation and you might need to reinstall and reconfigure other services if the domain controller runs additional services.

Manual SYSVOL relocation

To manually recreate the SYSVOL folder at the new location, copy the data from the existing location to the new location and then reconfigure FRS to point to the new location. Ensure that you properly copy all files to the new location.

Manually relocate SYSVOL only as a last resort, when you cannot remove and reinstall Active Directory on the domain controller. If you must perform this procedure, ensure that the SYSVOL replication between the domain controller and its replication partners is as up-to-date as possible. If the domain controller is not replicating properly with its partners, do not attempt to recreate SYSVOL until you determine why replication is not functioning and make the necessary fixes. For more information about recreating SYSVOL manually, see KB article Q304300 in the Microsoft Knowledge Base. To view the Microsoft Knowledge Base, see the Microsoft Knowledge Base link on the Web Resources page at <A HREF="http://go.microsoft.com/fwlink/?linkid=291" TARGET="_blank">http://www.microsoft.com/windows/reskits/webresources</A>.

SYSVOL Management Tasks and Procedures

Table 1.17 shows the tasks and procedures for managing SYSVOL.

Table 1.17   SYSVOL Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Change the space allocated to the Staging Area folder.	· Stop the File Replication service. · Change the space allocated to the Staging Area folder. · Start the File Replication service	· Regedit.exe	As needed
Relocate the Staging Area folder.	· Identify replication partners. · Check the status of the SYSVOL. · Verify replication is functioning. · Gather the SYSVOL path information. · Stop the File Replication service. · Create the new Staging Area folder. · Set the Staging Area path. · Prepare a domain controller for non-authoritative SYSVOL restore. · Start the File Replication service.	· Active Directory Sites and Services · Dcdiag.exe · Windows Explorer · ADSI Edit · Regedit.exe	As needed
Move SYSVOL by using the Active Directory Installation Wizard.	· View the current operations master role holders. · Transfer the forest-level operations master roles. · Transfer the domain-level operations master roles. · Determine whether a domain controller is a global catalog server. · Verify DNS registration and functionality. · Verify communication with other domain controllers. · Verify the existence of the operations masters. · Remove Active Directory. · Delete a server object from a site. · Verify DNS registration and functionality. · Install Active Directory. · Verify the site assignment for the domain controller. · Move a server object to a different site if the domain controller is located in the wrong site. · Perform final DNS configuration. · Check the status of the shared system volume. · Verify DNS registration and functionality. · Verify domain membership for the new domain controller. · Verify communication with other domain controllers. · Verify replication is functioning. · Verify the existence of the operations masters.	· Active Directory Users and Computers · Active Directory Sites and Services · Dcdiag.exe · Netdiag.exe · DCPromo.exe · DNS snap-in	As needed
Move SYSVOL manually.	· Identify replication partners. · Check the status of the shared system volume. · Verify replication is functioning. · Gather the SYSVOL path information. · Stop the File Replication service. · Create the SYSVOL folder structure. · Set the SYSVOL path. · Set the Staging Area path. · Set the fRSRootPath. · Prepare a domain controller for non-authoritative SYSVOL restore. · Update security on the new SYSVOL. · Start the File Replication service. · Check the status of the SYSVOL.	· Active Directory Sites and Services · Dcdiag.exe · NTBackup.exe · ADSI Edit · Regedit.exe · Linkd.exe	As needed
Update the SYSVOL path.	· Gather the SYSVOL path information. · Stop the File Replication service. · Set the SYSVOL path. · Set the fRSRootPath. · Set the Staging Area path. · Start the File Replication service.	· Regedit.exe · Windows Explorer · ADSI Edit · Linkd.exe	As needed
Restore and rebuild SYSVOL.	· Identify replication partners. · Check the status of the SYSVOL. · Verify replication is functioning. · Restart the domain controller in Active Directory Restore Mode (locally or remotely). · Gather the SYSVOL path information. · Stop the File Replication service. · Prepare the domain controller for non-authoritative SYSVOL restore. · Import the SYSVOL folder structure. · Start the File Replication service. · Check the status of the shared system volume.	· Active Directory Sites and Services · Dcdiag.exe · Windows Explorer · Regedit.exe · Linkd.exe	As needed

Changing the Space Allocated to the Staging Area

The Staging Area is a folder inside the SYSVOL folder. FRS replicates files by making copies of the files, storing these copies in the Staging Area folder, and then sending them to replication partners. Because FRS replicates a copy of the file, the original file remains available for user access during replication.

The Staging Area stores files prior to being replicated and stores files that it has just received through replication. Although FRS compresses the data and attributes of the replicated files to save space in the Staging Area folder and reduce the time that is needed to replicate the files, this method requires making and storing a copy of every file prior to replication and can require a substantial amount of disk space to store all of the copies.

When you examine the disk space that SYSVOL uses, you need to examine both physical disk space and allocated disk space. Physical disk space refers to the amount of space that is available on the disk drive. To prevent SYSVOL from using all physical disk space available on the drive, an entry in the registry limits the amount of space that SYSVOL can use. This is the allocated disk space.

The default size of the Staging Area folder is 675 megabytes(MB). The minimum size is 10 MB and the maximum size is 2 terabytes. You can adjust the size limit of the Staging Area folder by setting the value in kilobytes (KB) of the Staging Space Limit registry entry in HKEY_Local_Machine\System\CurrentControlSet\Services\NtFrs\Parameters. For more information about setting the Staging Space Limit in the registry, see KB article Q221111 in the Microsoft Knowledge Base. To view the Microsoft Knowledge Base, see the Microsoft Knowledge Base link on the Web Resources page at <A HREF="http://go.microsoft.com/fwlink/?linkid=291" TARGET="_blank">http://www.microsoft.com/windows/reskits/webresources</A>.

When the Staging Area folder runs out of disk space, FRS behaves differently depending on the version of Windows 2000 Server that is running. If Windows 2000 Server Service Pack 2 (SP2) or earlier is running, then FRS fills the Staging Area to the limit defined in the registry and then suspends inbound and outbound replication until disk space is made available. In this situation, you can avoid suspension of replication by generously estimating the amount of disk space that SYSVOL requires.

If Windows 2000 Server Service Pack 3 (SP3) is running, then FRS fills the Staging Area to 90 percent of the limit specified in the registry and then starts removing the least recently used files to make more space available. While this prevents FRS from suspending replication, it can affect the performance of the domain controller. If a large number of files are constantly being updated, then FRS constantly stages, removes, and restages files to maintain available disk space in the Staging Area. In this case, making more space available reduces the amount of work that the domain controller performs in order to keep FRS functioning.

Other Considerations for Estimating Required Disk Space

Both FRS and DFS use the Staging Area folder. The Staging Space Limit in the registry applies to the sum of the space that is used by DFS and FRS. To maintain sufficient disk space for SYSVOL, estimate the amount of space that DFS uses as well as the space that FRS uses.

If a file changes, FRS replicates the entire file and not just the change. If two replication partners have different values set for the Staging Space Limit, the maximum size of a file that FRS can replicate is the lower of the two values.

The Staging Area folder holds files from all replication partners. You must consider traffic to and from all partners when you estimate the disk space requirements for the Staging Area folder in each SYSVOL.

Active Directory replication uses connection objects to establish connections between replication partners. FRS uses the same connections for its own replication. Two factors control the rate that replication can take place over those connections: availability of the connection and transmission speed of the network. Each connection object has an associated schedule that allows administrators to dictate when the connection is available for replication. Network administrators can limit the time that replication can take place so that processes that are more important to the daily operation of the business can use available network bandwidth over a specific connection. This becomes especially important if two replication partners are connected by a slow link (such as a 128 Kbps dial-up connection). The schedule makes it possible to limit replication traffic so that it occurs only at night or during off-peak hours.

FRS stages all replication traffic and waits for the connection to become available. When the connection is available, it begins replication and continues until it replicates all outstanding files, or the connection becomes unavailable. If many files are awaiting replication and the network is busy handling other traffic, then FRS might not get a chance to replicate all outstanding files before the schedule makes the connection unavailable. If this happens, FRS holds the remaining files until the schedule permits replication to continue. While FRS is waiting for the schedule to permit replication, it continues to stage new files for replication. The Staging Area folder needs enough space to store the staged files as well as to handle any backlog of files that might not get replicated due to limited availability of the connection.

Procedures for Changing the Space Allocated to the Staging Area

Use the following procedures to change the amount of space that is allocated to the Staging Area folder. Procedures are explained in detail in the linked topics.

1. Stop the File Replication service.

2. Change the space allocated to the Staging Area folder.

3. Start the File Replication service.

Relocating the Staging Area

The Staging Area folder is likely to use most of the disk space that is allocated to SYSVOL. This is because the Staging Area folder stores all inbound and outbound files, and sometimes multiple copies of those files. As the disk space requirements increase, you can allocate more space until you reach 2 terabytes or the physical limit of the disk drive. The maximum disk space allowed for the Staging Area is 2 terabytes. If you reach the limit of the disk drive and still have not reached the 2 TB limit, consider relocating the Staging Area folder to a different disk that has more space available.

By default, the Active Directory Installation Wizard installs the Staging Area folder within the SYSVOL. The Active Directory Installation Wizard creates two folders, Staging and Staging Area, which FRS uses for the staging process. When you relocate the Staging Area, you can change the folder name. Ensure that you identify the proper folder in case the folder is renamed in your environment.

Two parameters determine the location of the Staging Area. One parameter, fRSStagingPath, is stored in the directory and contains the path to the actual location that FRS uses to stage files. The other parameter is a junction point stored in the Staging Areas folder in SYSVOL that links to the actual location that FRS uses to stage files. When relocating the Staging Area, you must update these two parameters to point to the new location.

Procedures for Relocating the Staging Area Folder

Except where noted, perform these procedures on the domain controller that contains the Staging Area folder that you want to relocate. Procedures are explained in detail in the linked topics.

1. Identify replication partners.

2. On the replication partners, check the status of the shared system volume. You do not need to perform the test on every partner, but you need to perform enough tests to be confident that the shared system volumes on the partners are healthy.

3. Verify that replication is functioning.

4. Gather the SYSVOL path information.

5. Stop the File Replication service.

6. Create the new Staging Area folder.

7. Set the Staging Area path.

8. Prepare a domain controller for non-authoritative SYSVOL restore.

9. Start the File Replication service.

Moving SYSVOL by Using the Active Directory Installation Wizard

Relocate SYSVOL only as a last resort. The many steps involved present many opportunities to incorrectly configure the system. If you must relocate SYSVOL, use the Active Directory Installation Wizard because it is far easier and more reliable that manually moving SYSVOL. The Active Directory Installation Wizard asks for the new location and then automatically configures the system for you.

Although using the Active Directory Installation Wizard is the preferred method for relocating SYSVOL, it is also the least practical because it involves decommissioning the domain controller. When this process is used, the Active Directory Installation Wizard is run on the domain controller to remove Active Directory. After Active Directory is removed, you run the wizard again to reinstall Active Directory. During the reinstallation, the wizard asks where you want to store SYSVOL. You enter the new location and the wizard configures it for you.

Using the Active Directory Installation Wizard to relocate SYSVOL can be too impractical for two reasons. First, because you are removing Active Directory and then reinstalling it, you also need to reinstall any other services that depend on Active Directory that are running on that domain controller. This can amount to hours of additional work and an unacceptable amount of time for the domain controller to be unavailable. Second, if a large number of objects exist in your directory, it can take hours or even days to complete the reinstallation when the new domain controller joins the network and completes the initial replication of the directory.

If this domain controller is not hosting any additional services that depend on the directory, and your directory does not take an extensive amount of time to complete the initial replication to new domain controllers, then moving SYSVOL with the Active Directory Installation Wizard can save you time and be easier and more reliable than moving SYSVOL manually.

WARNING

Do not move SYSVOL with the Active Directory Installation Wizard unless you completely understand the risks and consequences of decommissioning the domain controller in question.

Procedures for Moving SYSVOL with the Active Directory Installation Wizard

Use the following procedures to remove and reinstall Active Directory in order to move SYSVOL. For more information about installing and removing Active Directory, see “Managing Installation and Removal of Active Directory” in this guide. Procedures are explained in detail in the linked topics.

1. View the current operations master role holders to see if any roles are assigned to this domain controller.

2. If this domain controller is listed as hosting either the schema master or domain naming master roles, then transfer the forest-level roles to another domain controller in the forest root domain. Any domain controller in the forest is capable of hosting these roles but it is recommended that they remain in the forest root domain. Ensure that you place the domain naming master role on a global catalog server.

3. If this domain controller is listed as hosting the primary domain controller (PDC) emulator, infrastructure master or relative identifier (RID) master roles, transfer the domain-level roles to another domain controller in the same domain. Do not place the infrastructure master role on a global catalog server unless all of the domain controllers host the global catalog or unless only one domain exists in the forest.

4. Determine whether a domain controller is a global catalog server and ensure that other domain controllers are configured as global catalog servers before continuing.

5. Verify DNS registration and functionality.

6. Verify communication with other domain controllers.

7. Verify the existence of the operations masters on the network.

Note

If any of the verification tests fail, do not continue until you identify and fix the problems. If these tests fail, the decommissioning operation is also likely to fail.

8. Remove Active Directory.

9. Delete the server object from a site.

10. Verify DNS registration and functionality.

Note

If the verification test fails, do not continue until you identify and fix the problems. If the test fails, then installation is also likely to fail.

11. Install Active Directory. Provide the wizard with the new location for SYSVOL when prompted.

12. Verify the site assignment for the domain controller.

13. Move a server object to a different site if the domain controller is located in the wrong site.

14. Perform final DNS configuration for a new domain controller that is located in the forest root domain:

a. Create a delegation for the new domain controller in the parent domain of the DNS infrastructure if a parent domain exists and a DNS server hosts it. If a DNS server does not host the parent domain, then follow the procedures outlined in the vendor documentation to add the delegation for the new domain controller.

b. Configure the DNS client settings.

–Or–

Perform final DNS configuration for a new domain controller that is located in a child domain:

c. Create a delegation for the new domain controller in the forest root domain.

d. Create a secondary zone.

e. Configure the DNS client settings.

15. Check the status of the shared system volume.

16. Verify DNS registration and functionality.

17. Verify domain membership for the new domain controller.

18. Verify communication with other domain controllers.

19. Verify that replication is functioning.

20. Verify the existence of the operations masters.

Moving SYSVOL Manually

If you must move the entire system volume, not just the Staging Area folder, and you have determined that moving the system volume by using the Active Directory Installation Wizard is impractical, then you can relocate the system volume manually. Because no utilities can automate this process, you must carefully ensure that you properly move all folders and maintain the same level of security at the new location.

Regardless of the method used to move SYSVOL, these events occur:

· The File Replication service is stopped.

· The proper folder structure is created at the new location.

· The SYSVOL path information is updated in the directory and in the registry.

· Default security settings are set on the new folder structure.

· The File Replication service is restarted.

FRS is stopped while the changes are made and then restarted after the changes are completed. During the restart process, FRS reads the new configuration information in the directory and the registry and reconfigures itself to use the new location.

SYSVOL uses an extensive folder structure that must be recreated accurately at the new location. The easiest method is to copy the folder structure by using Windows Explorer. You must ensure that you copy any folders that may have special attributes, such as hidden folders.

The folder structure also includes junction points. Junction points look like folders when they appear in Windows Explorer but they are not really folders. Junction points contain links to other folders. When you open a junction in Windows Explorer, you see the contents of the folder to which the junction is linked. If you open a command prompt and display a directory listing that contains junction points, they are designated as <JUNCTION>, while regular folders are designated with <DIR>. Junction points behave like regular folders. When you are working in the file system, you have no indication whether you are working with a junction or a folder.

The difference between folders and junctions appears when you copy or move a junction to a new location. Because a junction is a link to another location, when you copy a junction to a new location, the link still refers to the original location. SYSVOL contains two junction points that point to folders in the SYSVOL tree. When you move the tree to a new location, you must update the junction points to point to the new location. Otherwise, the junction points continue to point to the original SYSVOL folders.

The registry and Active Directory store path information that FRS uses to locate the SYSVOL and the Staging Area folders. You must update these settings to point to the new locations.

After you create the new folders and update the paths and junctions, ensure that the folders get repopulated with the proper data. You can repopulate the files stored in SYSVOL at the new location is done by replicating the data into the new location from one of the domain controller’s replication partners. The BURFLAGS option is set in the registry and when FRS restarts, it replicates the data into the new folders from one of the replication partners. Because this data is restored to the new location by means of replication, be certain that the system volumes on the replication partners are updated and functioning properly to ensure that the data replicated into the new folders is updated and has no errors.

Important

Remember, if the system volumes on your domain controllers are becoming unsynchronized to the point that you need to relocate the system volumes, be sure to troubleshoot the FRS problems and resolve the issues that cause the system volumes to become unsynchronized before you attempt to relocate the system volumes.

Procedures for Moving SYSVOL Manually

Except where noted, perform these steps on the domain controller that contains the system volume that you want to move. Procedures are explained in detail in the linked topics.

WARNING

This procedure can alter security settings. After you complete the procedure, the security settings on the new system volume are reset to the default settings that were established when you installed Active Directory. You must reapply any changes to the security settings on the system volume that you made since you installed Active Directory. Failure to do so can result in unauthorized access to Group Policy objects and logon and logoff scripts.

1. Identify replication partners.

2. On the replication partners, check the status of the shared system volume. You do not need to perform the test on every partner, but you need to perform enough tests to be confident that the shared system volumes on the partners are healthy.

3. Verify that replication is functioning.

4. Gather the SYSVOL path information.

5. Stop the File Replication service.

6. Create the SYSVOL folder structure.

7. Set the SYSVOL path.

8. Set the Staging Area path. If you have moved the Staging Area folder to a different location already, you do not need to do this step.

9. Set the fRSRootPath.

10. Prepare a domain controller for non-authoritative SYSVOL restore.

11. Update security on the new SYSVOL.

12. Start the File Replication service.

13. Check the status of the shared system volume.

Updating the System Volume Path

Due to system maintenance, you might need to update the system volume path. When you add or remove disk drives, the logical drive letters of the other drives on the system can change. If either your SYSVOL or Staging Area folder is located on one of the drives whose letter changes, FRS cannot locate them. You must update the paths that FRS uses to locate these folders to solve this problem. To change the path for the system volume, make changes to the registry and in the directory. Changing the Staging Area path requires a change in the directory. Both changes require that you update the junction points. After updating the path information, you must restart FRS so it can reinitialize with the new values.

Procedures for Updating the System Volume Path

Use the following procedures to change the amount of space that is allocated to the Staging Area folder. Procedures are explained in detail in the linked topics.

1. Gather the System Volume path information.

2. Stop the File Replication service.

3. Set the SYSVOL path (if needed).

4. Set the fRSRootPath (if needed).

5. Set the Staging Area path (if needed).

6. Start the File Replication service.

Restoring and Rebuilding SYSVOL

In some cases, you must recreate or rebuild the SYSVOL on a single domain controller. Attempt to rebuild SYSVOL on a single domain controller only when all other domain controllers in the domain have a healthy and functioning SYSVOL. Do not attempt to rebuild SYSVOL until you correct any problems that are occurring with FRS in a domain.

Procedure for Restoring and Rebuilding SYSVOL

Use these procedures only if you are working on a domain controller that does not have a functional SYSVOL. Procedures are explained in detail in the linked topics.

1. Identify replication partners.

2. Choose a partner and check the status of the SYSVOL on the partner. Because you will be copying the system volume from one of the partners, you need to make sure that the system volume you copy from the partner is up-to-date.

3. Verify that replication is functioning on the partner.

4. Restart the domain controller that is being repaired in Directory Services Restore Mode. If you are sitting at the console of the domain controller, locally restart a domain controller in directory services restore mode. If you are accessing the domain controller remotely using Terminal Services, remotely restart a domain controller in directory services restore mode.

5. Gather the SYSVOL path information.

6. Stop the File Replication service.

7. Prepare a domain controller for non-authoritative SYSVOL restore.

8. Import the SYSVOL folder structure.

9. Start the File Replication service.

10. Check the status of the shared system volume.

Managing Windows Time Service

The Windows 2000 time service, W32Time, requires little management and is installed by default on all Windows 2000–based computers. W32Time uses coordinated universal time (UTC), which is based on an atomic time scale and is independent of time zone.

On computers that are joined to a domain, time synchronization occurs when the W32Time service starts during system startup. The Net Logon service looks for a domain controller that can authenticate and synchronize time with the client.

Time Configuration on the Forest-Root PDC Emulator

The time service uses a hierarchical relationship that controls authority and ensures common time usage. By default, the PDC emulator in the forest root domain is the authoritative time source for that forest.

Follow these best practices for configuring time on the forest-root PDC emulator, in this order of preference:

· Install a hardware clock that uses the Network Time Protocol (NTP) on an internal network, and synchronize the forest-root PDC emulator and the standby PDC emulator to it.

· Use IPSec to securely synchronize with another network time server.

· Monitor the forest-root PDC emulator closely to ensure that its time is accurate. Do not synchronize the forest-root PDC emulator with another computer.

If none of these options are acceptable in your organization, you can synchronize with an external reliable time source. However, this option is not recommended, as it synchronizes time in an unauthenticated manner, potentially making time packets vulnerable to an attacker.

System Time Maintenance

Do not advance or roll back the system time on Windows 2000–based servers under any circumstances, including attempts to:

· Test significant time and date transitions such as Year 2000 testing.

· Force the deletion of tombstones (objects that have been marked for deletion in the Active Directory).

· Make objects on one computer override the objects on another computer.

· Extend the useful life of a system backup.

· Return a computer to an earlier system state including schema rollback.

· Incorporate test environments into production, after you test time and date transitions on lab computers.

· Troubleshoot Active Directory or File Replication Service (FRS) issues, by advancing the system time of a computer in an effort to make the content of one computer authoritative over another. Advancing the time can adversely affect the operation of the system, and it is not a useful method of resolving Active Directory or FRS replication problems.

How advancing system time affects FRS

Advancing the system time affects FRS in the following manner:

u· Active Directory prematurely deletes tombstones for deleted objects, causing incorrect reconciliation later. When an object is deleted, it is not actually removed from the database. It is instead marked for deletion after 60 days by default. This tombstone is replicated to other domain controllers. When the tombstone expires, the object is then permanently deleted. If the tombstone is deleted prematurely, then updates from replication partners are inconsistent.

u· Local file changes create change orders with event times reflecting the advanced clock time. These change orders are inserted into the outbound log but are not sent because the computer with the advanced clock will not join with the partners that remain at the correct time. Later, when the time on this computer is restored to the correct time and the computer is able to join with its outbound partners, it sends the change orders with the advanced event time. The downstream partner ignores these change orders because the event time is too far into the future. The result is that the files that changed while the time was advanced are not replicated to the other members, but remain on the computer. Furthermore, the advanced event times cause the computer to reject updates to these files that originate from other replication partners.

How advancing system time affects Active Directory

Advancing the system time affects Active Directory in the following manner:

u· Replication conflicts might be incorrectly resolved. Active Directory uses the time service to resolve replication conflicts. When the same attribute on the same object is changed on two different servers during a latency period, the most recent change is replicated. Thus, if you advance the time on a computer, all changes originating on that computer appear as more recent changes and are replicated despite the fact that they might not be the most recent changes.

u· Name conflicts might be incorrectly resolved. Active Directory also uses the time service to resolve name conflicts. When two different objects with the same name are created on two servers, Active Directory saves the most recently created object. Advancing the time on a computer might cause Active Directory to save the wrong object simply because it reflects a more recent change.

u· Restoring from a backup might fail. Backups are only good for the period of the tombstone lifetime. When you back up the system state, Active Directory generates an expiry token. The token is submitted when you restore the system state from the backup and is used to verify that the backup is not too old. Attempting to restore a backup after you advance the system clock might make the backup appear too old and cause the backup to fail. Do not restore a backup that you made from a computer with an advanced time setting.

u· Link value replication is impaired. Link value replication uses a timestamp to distinguish values. Changing the system clock hinders this mechanism.

u· Kerberos authentication might fail. Kerberos authentication is based on clock synchronization. Furthermore, the lifetimes of the Kerberos tickets are exceeded if the clock is moved too far ahead.

Windows Time Service Management Tasks and Procedures

Table 1.18 lists the tasks and procedures for managing Windows Time Service.

Table 1.18   Windows Time Service Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Configure a time source for the forest.	§· Configure time on the forest-root PDC emulator. §· Remove a time source configure on the forest-root PDC emulator.	· Net time	As needed
Configure a reliable time source on a computer other than the PDC emulator.	§· Configure the selected computer as a reliable time source.	· Regedit.exe	As needed
Configure a client to request time from a specific time source.	§· Set a manually configured time source on a selected computer. §· Remove a manually configured time source on a selected computer.	· Net time	As needed
Optimize the polling interval.	§· Change polling interval.	· W32tm.exe · Regedit.exe	As needed
Disable the Windows Time Service.	§· Disable time service.	· Active Directory Sites and Services	As needed

Configuring a Time Source for the Forest

After initial deployment of your network, you typically only reconfigure the time service on the PDC emulator in two situations:

u· If you move the PDC emulator role to a different computer. In this case, you must configure the time source on the new role holder.

u· If you change your time source. For example, if you change from synchronizing with an external source to an internal hardware device.

Procedures for Configuring Time on the Forest-Root PDC Emulator

To configure time service for the forest-root PDC emulator, you might need to remove an external time source that you used previously, or, if you transferred that operations master role, you might only need to configure the time service on the new PDC emulator. To configure time on the forest-root PDC emulator, you can use the following procedures. Procedures are explained in detail in the linked topics.

1. Configure time on the forest-root PDC emulator.

2. Remove a time source configured on the forest-root PDC emulator.

Configuring a Reliable Time Source on a Computer Other than the PDC Emulator

By default, the PDC emulator in the forest root is the authoritative time source for that forest. However, you might want to configure a different computer in your network to be authoritative for the forest, in the following situations:

u· If you plan to move the PDC Operations Master role, you can configure a reliable time source on a different computer prior to the move(s) to avoid resets or disruption of the time service. The role of PDC emulator can move between computers, which means that every time the role of PDC emulator moves, the new PDC emulator must be manually configured to point to the external source, and the manual configuration must be removed from the original PDC emulator. To avoid this process, you can set one of the domain controllers in the parent domain as reliable and manually configure just that computer to point to an external source. Then, no matter which computer is the PDC emulator, the root of the time service stays the same and thus remains properly configured.

u· If you have security reasons for wanting to segregate the authoritative time computer.

When domain controllers look for a time source to synchronize with, they choose a reliable source if one is available. It is important to note that the automatic discovery mechanism in the time service client never chooses a computer that is not a domain controller. Clients must be manually configured to use any server that is not a domain controller.

Note

Setting a computer that is already synchronizing from the domain hierarchy as a reliable time source can create loops in the synchronization tree and cause unpredictable results.

Procedure for Configuring a Reliable Time Source on a Computer Other than the PDC Emulator

Although the PDC emulator in the forest root domain is the authoritative time source for that forest, you can configure a reliable time source on a computer other than the PDC emulator.

· Configure the selected computer as a reliable time source.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see “Active Directory Backup and Restore” in this guide.

Configuring a Client to Request Time from a Specific Time Source

Certain computers do not automatically synchronize their time through the Windows 2000 time service hierarchy, so you might want to configure these clients to request time from a specific source. If you do not specify a source, each computer’s internal hardware clock governs its time. The following client computers do not automatically synchronize through the time service:

u· Client computers that run Windows NT 4.0

u· Client computers that run UNIX

u· Computers that are not members of a domain

Note

Manually specified time sources are not authenticated, and therefore can enable an attacker to manipulate the time source and then start Kerberos V5 replay attacks. Also, a computer that does not synchronize with its domain controller can have an unsynchronized time. This causes Kerberos V5 authentication to fail, which in turn causes other actions requiring network authentication, such as printing or file sharing, to fail. When only one computer in the forest root domain is getting time from an external source, all computers within the forest remain synchronized to each other, making replay attacks difficult.

Procedures for Configuring a Client to Request Time from a Specific Time Source

The following procedures allow you to specify a time source for client computers that do not automatically synchronize through the time service. Procedures are explained in detail in the linked topics.

1. Set a manually configured time source on a selected computer.

2. Remove a manually configured time source on a selected computer.

Optimizing the Polling Interval

By default, the time service synchronizes once every 45 minutes until three successful synchronizations occur, then once every eight hours. You might want to change this interval in the following situations:

u· If computers are polling over a paid line, you can increase the polling interval. By polling less often, you will decrease usage of the paid line.

u· If you have applications or devices that require increased time accuracy, you can decrease the polling interval.

Procedure for Optimizing the Polling Interval

You only need to perform one procedure to disable the Windows Time service.

u· Change polling interval.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see “Active Directory Backup and Restore” in this guide.

Disabling the Windows Time Service

If you choose to implement another time synchronization product that uses the NTP protocol, you must disable the W32Time time service because all NTP servers need access to UDP port 123. If W32Time is running on a Windows 2000–based computer, port 123 remains occupied.

Procedure for disabling the Windows Time service

You only need to perform one procedure to disable the Windows Time service.

u· Disable time service.

Managing Long-Disconnected Domain Controllers

A disconnected domain controller is a domain controller that is not replicating. Domain controllers can become disconnected deliberately or inadvertently. Short-term disconnections are not problematic because Active Directory replication automatically updates domain controllers with all changes that they have not received. However, if a domain controller must be separated from the replication topology for several weeks, you can take preliminary steps to ensure a smooth reconnection.

For example, when domain controllers must be moved long distances or are pre-staged and possibly stored for a period of time prior to being shipped to a destination, you must prepare them to ensure that no gaps occur in operations master coverage during the disconnection and that SYSVOL is updated when you reconnect the domain controller. If you plan to disconnect a domain controller for longer than a domain controller keeps track of object deletions, you must take additional steps to ensure directory consistency, as described in “Preparing a Domain Controller for a Long Disconnection” later in this section.

By monitoring replication, you can detect disconnections that occur due to network failures, service failures, or configuration errors. For information about implementing monitoring for replication failures, see “Monitoring Active Directory” earlier in this guide.

Operations Master Considerations

If a domain controller holds an operations master role, you must transfer the role prior to disconnecting the domain controller. Normal directory functioning depends on all roles being active, so when you plan to disconnect the domain controller, you must first transfer any operations master roles. Role transfer ensures that no gaps in master operations coverage occur, which can cause directory inconsistencies. For information about transferring operations master roles, see “Managing Operations Masters” earlier in this guide.

Active Directory Replication Considerations

Ensure that the domain controller is updated before you disconnect it. Immediately prior to disconnecting the domain controller, force replication with all replication partners and verify that each directory partition replicates to the domain controller that you are disconnecting. If replication of any directory partition does not succeed, resolve the replication problem prior to disconnecting. By ensuring that replication is up-to-date, you can maximize the possible safe disconnection period, which cannot exceed the tombstone lifetime for the forest. For information about estimating the maximum safe disconnection period, see “Preparing a Domain Controller for a Long Disconnection” later in this guide.

Tombstone Lifetime and Backup Considerations

Active Directory backups are useful for recovering a domain controller for only as long as the tombstone lifetime. When an object is deleted, Active Directory replicates the object as a tombstone, which consists of a small subset of the attributes of the deleted object. The tombstone is retained in Active Directory for 60 days by default, after which it is permanently removed. Because a domain controller that is disconnected for longer than the tombstone lifetime cannot receive deletions that occurred prior to the beginning of the tombstone lifetime, a backup that is older than the tombstone lifetime cannot be used to restore Active Directory.

When conditions beyond your control cause a domain controller to be disconnected longer than the tombstone lifetime, one or more objects that have been deleted from the rest of the directory while the domain controller was offline might remain on the disconnected domain controller. The best practice recommendation for reconciling this condition of inconsistency is to reinstall Windows on the outdated domain controller and then reinstall Active Directory. Otherwise, the outdated domain controller can potentially reintroduce (reanimate) objects into Active Directory that were deleted while the domain controller was disconnected. For information about how objects become reanimated in Active Directory, see “Reconnecting Long-Disconnected Domain Controllers” later in this guide.

If planned domain controller disconnections are consistently lasting longer than 60 days, alert the design team and consider extending the tombstone lifetime for the forest.

SYSVOL Consistency Considerations

SYSVOL is a file system folder that stores files that must be available and synchronized among all domain controllers. SYSVOL contains the NETLOGON share, Group Policy settings, and File Replication service (FRS) staging directories and files. SYSVOL is required for Active Directory to function properly.

SYSVOL is replicated by the File Replication service (FRS). FRS has a fixed tombstone lifetime of 60 days. Because you cannot change this interval, any domain controller that is disconnected for more than 60 days potentially has an outdated SYSVOL. Updating SYSVOL requires performing a non-authoritative restore of SYSVOL.

In addition, SYSVOL replication cannot be synchronized manually. For this reason, ensuring that SYSVOL is updated prior to disconnecting the domain controller is more difficult than simply updating SYSVOL when the domain controller is reconnected. Regardless of the length of the disconnection, to ensure that SYSVOL is synchronized when the domain controller is reconnected, prepare the domain controller to perform a non-authoritative restore of SYSVOL prior to disconnecting it. When it restarts, non-authoritative restore of SYSVOL occurs automatically. For information about performing non-authoritative restore of SYSVOL, see “Restoring and Rebuilding SYSVOL” earlier in this guide.

Windows 2000 Server with SP3

Windows 2000 Server with Service Pack 3 (SP3) provides the ability to force strict replication consistency, which prevents outdated domain controllers from reintroducing objects that no longer exist in Active Directory. When deploying new domain controllers that are running Windows 2000 Server SP3, modify the registry to enforce strict replication consistency. For information about strict replication consistency, see “Removing Lingering Objects from an Outdated Writable Domain Controller” in this guide. For information about installing domain controllers, see “Installing and Removing Active Directory” earlier in this guide.

Best Practice Recommendations for Managing Long Disconnections

If you must disconnect a domain controller for a period of several weeks or months, follow these recommendations:

· Prior to disconnecting, determine the maximum length of time that the domain controller will be disconnected and subtract a generous estimate of the end-to-end replication latency. This amount of time is the maximum period for which the domain controller can safely be disconnected.

· Prior to disconnecting, determine the value of the tombstone lifetime for the forest. If you estimate the maximum safe time of disconnection to be longer than the tombstone lifetime, contact a supervisor. The design team must determine whether to extend the tombstone lifetime or rebuild the domain controller prior to reconnecting it.

· Prior to disconnecting, prepare the registry for automatic non-authoritative restore of SYSVOL when the domain controller restarts.

· Immediately prior to disconnecting, ensure that the domain controller replicates successfully with all replication partners.

· When you disconnect the domain controller, attach a label to the computer that identifies the date and time of disconnection.

· When reconnecting the domain controller, if the site contains no other domain controller that is authoritative for the domain, time the restart of the domain controller to coincide with the beginning of intersite replication to restore SYSVOL as quickly as possible. If the site has one or more other domain controllers that are authoritative for the domain, start the domain controller at any time.

· If a domain controller has been disconnected for longer than the maximum safe time of disconnection (tombstone lifetime less end-to-end replication latency), do not allow the domain controller to replicate. Reinstall Windows 2000 Server. This recommendation applies to all such domain controllers, regardless of the version of Windows 2000 Server they are running (SP3, SP2, or earlier).

· If you deploy Windows 2000 Server SP3, modify the registry to enforce strict replication behavior at the time the domain controller is installed.

Tasks and Procedures for Managing Long-Disconnected Domain Controllers

Table 1.19 shows the tasks and procedures for managing long disconnected domain controllers, including tasks that address removing lingering objects.

Table 1.19   Tasks and Procedures for Managing Long-Disconnected Domain Controllers

Tasks	Procedures	Tools	Frequency
Prepare a domain controller for long disconnection.	· Determine the anticipated length of the disconnection. · Determine the tombstone lifetime for the forest. · Determine the maximum safe disconnection time and proceed as follows: · If the estimated time of disconnection exceeds the maximum safe disconnection time, do not proceed with the disconnection. Contact a supervisor. · If the estimated time of disconnection does not exceed the maximum safe disconnection time, proceed with disconnection. · View the current operations master role holders. · Transfer domain-level operations master roles, if appropriate. · Transfer forest-level operations master roles, if appropriate. · Prepare the domain controller for non-authoritative SYSVOL restore. · Synchronize replication from all inbound (source) replication partners. · Verify successful replication to the domain controller. · Label the domain controller with the date and time of disconnection and the maximum safe disconnection period.	· ADSI Edit · Active Directory Sites and Services · Repadmin.exe · Regedit.exe · Active Directory Domains and Trusts · Active Directory Users and Computers	As needed
Reconnect a long-disconnected domain controller.	· Determine the tombstone lifetime for the forest. · Determine whether the maximum safe disconnection time has been exceeded, and proceed accordingly. · If the maximum safe time has been exceeded, do not connect the domain controller. Contact a supervisor about reinstalling the domain controller. · If the maximum safe time has not been exceeded, proceed with reconnecting. · If the site has one or more other domain controllers that are authoritative for the domain, start the domain controller at any time. · If domain updates are available only from a different site: · Determine when intersite replication is scheduled to begin. · As soon as possible after the next replication cycle begins, start the domain controller. · Verify successful replication on the reconnected domain controller.	· ADSI Edit · Active Directory Sites and Services · Repadmin.exe	As needed
Remove lingering objects from an outdated writable domain controller.	Windows 2000 Server with SP2: · Identify a revived lingering object and replication source on a writable domain controller. · Disable outbound replication on the outdated source domain controller. · Delete the object from the outdated source domain controller. Windows 2000 Server with SP3: · Identify and delete a known non-replicated lingering object on an outdated domain controller. Windows 2000 Server with SP2 or SP3, continue as follows: · Identify unknown lingering objects on an outdated domain controller. · View replication metadata of the objects. · Delete objects created prior to domain controller disconnection. · Restart disabled outbound replication (SP2 only). · Synchronize replication from the outdated domain controller to a replication partner.	· Event Viewer · Active Directory Sites and Services · Repadmin.exe · Dsastat.exe · Active Directory Users and Computers	As needed
Remove lingering objects from a global catalog server.	· Windows 2000 Server with SP2: · Contact Microsoft Product Support Services. · Windows 2000 Server with SP3: · Establish the distinguished name and Globally Unique Identifier (GUID) of the object. · Identify the GUID of a domain controller that has a writable replica of the domain. · Delete the lingering object from the global catalog server.	Ldp.exe	As needed

Preparing a Domain Controller for a Long Disconnection

When you need to take a domain controller offline for a prolonged period, prepare the domain controller by doing the following:

· Establish the maximum safe disconnection period. Determine the tombstone lifetime interval and subtract a generous estimate of the end-to-end replication latency to establish the maximum safe period of disconnection. Otherwise, even when the domain controller is reconnected prior to the end of the tombstone lifetime, a tombstone can potentially expire before reaching the reconnected domain controller.

· Verify replication success on the domain controller prior to disconnecting it. If replication is not successful, troubleshoot and fix the problem prior to disconnecting the domain controller.

· Modify the registry to prepare the domain controller to perform a non-authoritative restore of SYSVOL when it restarts. SYSVOL inconsistencies are not easily verifiable prior to disconnecting. Therefore, by setting the registry to restore SYSVOL when the domain controller restarts, you can ensure that SYSVOL reinitializes its membership in the replica set and updates its content at the earliest opportunity after reconnecting the domain controller.

· When modifying the registry to restore SYSVOL, consider the following:

· If SYSVOL is the only replica set that is represented on the domain controller, modify the global BurFlags registry entry.

· If other replica sets are represented on the domain controller and you want to update only SYSVOL, modify the replica-set-specific BurFlags registry entry for SYSVOL.

For information about restoring SYSVOL, see “Restoring and Rebuilding SYSVOL” earlier in this guide.

· Determine whether the domain controller holds an operations master role. If the domain controller is an operations master, transfer the role prior to disconnecting. For information about transferring operations master roles, see “Managing Operations Masters” earlier in this guide.

If the length of the disconnection is predicted to be longer than the current tombstone lifetime, consult the design team about extending the tombstone lifetime.

Procedures for Preparing a Domain Controller for Long Disconnection

Perform the following procedures prior to disconnecting a domain controller. Procedures are explained in detail in the linked topics.

1. Determine the anticipated length of the disconnection.

2. Determine the tombstone lifetime for the forest.

3. Determine the maximum safe disconnection period by subtracting a generous estimate of the end-to-end replication latency from the tombstone lifetime. Either find the latency estimate in the design documentation for your deployment, or request the information from a member of the design or deployment team.

· If the anticipated time of disconnection exceeds the maximum safe disconnection period, do not disconnect the domain controller. Contact a supervisor.

· If the estimated time of disconnection does not exceed the maximum safe disconnection time, proceed with disconnection.

4. View the current operations master role holders to determine whether the domain controller is an operations master role holder.

5. Transfer a domain-level operations master role, if appropriate.

6. Transfer a forest-level operations master role, if appropriate.

7. Prepare the domain controller for non-authoritative SYSVOL restore on the domain controller that you are disconnecting. This process ensures an up-to-date SYSVOL when the domain controller is restarted.

8. Synchronize replication from all inbound (source) replication partners. Each connection object below the NTDS Settings object for the server you are disconnecting represents an inbound replication partner.

9. Verify successful replication to the domain controller that you are disconnecting.

10. Label the domain controller with the date and time of disconnection and the maximum safe disconnection period.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see “Active Directory Backup and Restore” in this guide.

Reconnecting Long-Disconnected Domain Controllers

Assuming that the domain controller has not been disconnected for longer than the maximum safe period of disconnection (tombstone lifetime minus end-to-end replication latency), reconnecting it to the replication topology requires no special procedures. By default, the Knowledge Consistency Checker (KCC) on a domain controller runs 5 minutes after the domain controller starts, automatically incorporating the reconnected domain controller into the replication topology.

If you plan appropriately for disconnecting and reconnecting domain controllers, no domain controller will be disconnected from the replication topology for longer than a tombstone lifetime. However, if unexpected events result in a domain controller becoming outdated, do not reconnect the domain controller. Do not attempt to remove Active Directory because this process requires replication. To ensure directory consistency, reinstall Windows 2000 Server on the outdated domain controller. For information about how to reinstall a domain controller that has not replicated for longer than a tombstone lifetime, see “Recovering a Domain Controller Through Reinstallation.”

By monitoring replication, you avoid unexpected lengthy disconnections of domain controllers. For information about monitoring replication, see “Monitoring Active Directory” in this guide.

Long Disconnections and Tombstone Lifetime

If a domain controller remains disconnected for longer than a tombstone lifetime, an object that has been deleted from the directory can remain on the disconnected domain controller. For this reason, such objects are called “lingering objects.”

Lingering objects can occur in the following circumstances:

· A domain controller goes offline immediately prior to the deletion of an object on another domain controller and remains offline for:

· A period that exceeds the tombstone lifetime.

· A period that is less than the tombstone lifetime, but replication latency exceeds the remaining duration of the tombstone lifetime.

· A domain controller goes offline following the deletion of an object on another domain controller but prior to receiving replication of the tombstone, and remains offline for a period that exceeds the tombstone lifetime.

· A domain controller goes offline, an object is deleted on that domain controller, and the object tombstone is removed by garbage collection on that domain controller prior to the domain controller being reconnected to replication.

In the latter case, an object exists on all domain controllers in the domain (for a domain-specific object) or forest (for a configuration or schema object) except the reconnected domain controller. In this case, the remedy is simply to delete the object on any writable domain controller.

However, in the first two cases, if the domain controller is then reconnected to the replication topology, objects that exist nowhere else in the forest remain on the domain controller and potentially can be reintroduced into the directory.

If lingering objects are security principals, reintroducing them can have serious consequences. For more information about how lingering objects are reintroduced into the directory and how to remove them, see “Removing Lingering Objects from an Outdated Writable Domain Controller.”

Best Practice Recommendations for Avoiding Lingering Objects

Take the following precautions to ensure that lingering objects do not occur:

· Monitor the KCC topology and replication to ensure that long disconnections are detected. For information about monitoring the KCC and replication, see “Monitoring Active Directory” earlier in this guide.

· Ensure that the tombstone lifetime is not lowered below the default of 60 days.

· If you know that a domain controller will be offline for longer than the tombstone lifetime, consult the design team about increasing the tombstone lifetime to a period that safely encompasses the offline duration plus a generous period of replication latency.

· Install Windows 2000 Server SP3 as soon as possible and enable strict replication consistency to ensure that lingering objects cannot replicate.

Long Disconnections and SYSVOL

If the tombstone lifetime has been extended to longer than 60 days, SYSVOL will be outdated when you reconnect the domain controller. The recommended practice is to prepare a domain controller for a long disconnection by modifying the registry so that SYSVOL is restored automatically when the domain controller is restarted. To update SYSVOL as soon as possible after reconnecting, plan the time that you restart the domain controller to optimize the replication schedule, as follows:

· If the closest replication partner for the domain is in a different site, view site link properties to determine the schedule and then restart the domain controller as soon as possible after the schedule opens.

· If a replication partner for the domain is available within the site, verify replication success on that partner prior to restarting the domain controller.

Important

Do not use file copy utilities such as xcopy or robocopy to update an outdated SYSVOL.

In the event that a domain controller has been disconnected for a tombstone lifetime or longer but has already replicated, follow the instructions for detecting and removing lingering objects in “.Removing Lingering Objects from an Outdated Writable Domain Controller.”

Procedures for Reconnecting a Long-Disconnected Domain Controller

Follow these procedures to reconnect the domain controller. Procedures are explained in detail in the linked topics.

1. Determine the tombstone lifetime for the forest.

2. Determine whether the maximum safe disconnection time has been exceeded, and proceed accordingly:

a. If the domain controller has been disconnected for a period that exceeds the maximum safe disconnection period, do not reconnect the domain controller. Contact a supervisor about reinstalling the domain controller.

b. If the maximum safe time has not been exceeded, proceed with reconnecting.

3. If the site in which you are reconnecting the domain controller has one or more other domain controllers that are authoritative for the domain, start the domain controller at any time.

4. If the site in which you are reconnecting the domain controller has no other domain controllers that are authoritative for the domain, proceed as follows:

a. Determine when the next intersite replication cycle is scheduled to begin by viewing the replication properties on the site link that connects this site to the next closest site that includes domain controllers for this domain.

b. As soon as possible after the next replication cycle begins, start the domain controller.

5. After replication is complete, verify successful replication to the domain controller (the reconnected domain controller) of the domain, configuration, and schema directory partitions. If the domain controller is a global catalog server, check for successful replication of all domain directory partitions.

In the event that a domain controller has been disconnected for a tombstone lifetime or longer but has already replicated, follow the instructions for detecting and removing lingering objects in “Removing Lingering Objects from an Outdated Writable Domain Controller.”

Removing Lingering Objects from an Outdated Writable Domain Controller

If a domain controller does not replicate for a period that is longer than the tombstone lifetime and the domain controller is then reintroduced into the replication topology, objects that have been deleted from Active Directory while the domain controller was offline can remain on the domain controller as lingering objects.

Causes for Lingering Objects

Lingering objects can occur whenever a domain controller does not replicate for a period that exceeds the tombstone lifetime. Unexpectedly long disconnections can be caused by the following conditions:

· A domain controller is left in a storage room and forgotten, or shipment of the pre-staged domain controller to its remote location takes longer than a tombstone lifetime.

· Replication fails and monitoring is not in place. For example, if a bridgehead server is overloaded, replication can become backlogged indefinitely.

· WAN connections are unavailable for long periods. For example, a domain controller on board a cruise ship might be unable to replicate because the ship is at sea for longer than the tombstone lifetime.

· Garbage collection tampering. For example:

· Someone changes the time on a domain controller to force garbage collection.

· Someone changes the tombstone lifetime to force garbage collection.

Indications that a Domain Controller has Lingering Objects

An outdated domain controller can store lingering objects with no noticeable effect as long as no one updates the lingering object or tries to create an object with the same name in the domain or the same user principal name in the forest. However, the existence of lingering objects can cause problems, especially if the object is a security principal.

The following conditions indicate that a domain controller has lingering objects:

· A deleted user or group account does not disappear from the Global Address List on Exchange servers. Therefore, although the account name appears in the list, attempts to send mail result in errors.

· E-mail messages are not delivered to a user whose user object was moved between domains. After an outdated domain controller or global catalog server becomes reconnected, both instances of the user object appear in the global catalog. Both objects have the same e-mail address, so e-mail messages cannot be delivered.

· A universal group that no longer exists still appears in a user’s access token. Although the group no longer exists, if a user account still has the group in its security token, the user might have access to a resource that you intended to be unavailable to that user.

· A new object or Exchange mailbox cannot be created when the samAccountName attribute value of the new object is the same as a lingering object. An error reports that the object already exists.

· Replication succeeds with “no such object” error (event ID 1388) when “loose replication consistency” is in effect. This error indicates that the source domain controller revived a lingering object in the directory.

· Replication fails with a “no such object” error (event ID 1084) when “strict replication consistency” is in effect. This error indicates that the source domain controller tried to replicate a lingering object.

Replication of Lingering Objects

If a user updates a lingering object on the outdated domain controller, the destination domain controller that receives the request for the update cannot update the object because the object does not exist. The destination domain controller logs an NTDS Replication error in the Directory Service log in Event Viewer. The error that is reported depends on the type of replication consistency that is in effect on the domain controller.

The replication response differs on domain controllers that use loose replication consistency and domain controllers that use strict replication consistency. On domain controllers that use loose replication consistency (the default behavior with Windows 2000 Server SP2), the destination domain controller requests a full copy of the object from the replication source. If the object is being modified, the destination requests the full object and the object is revived in the directory. If the object is being deleted, the destination replicates the tombstone. In either case, the NTDS Replication event ID 1388 is logged in the Directory Service log by the destination. The error reports that the object being updated does not exist and the domain controller does not have enough information to create it, and so it will request a complete copy. This error alerts you to the fact that you have at least one lingering object and gives you the information that you need in order to locate that object and delete it if it has been revived. Deleting the revived object on a writable domain controller removes it from the directory

Domain controllers on which strict replication consistency is enabled (configurable behavior with Windows 2000 Server SP3) refuse replication from the outdated replication source. This action stops replication from the outdated source and logs NTDS Replication event ID 1084 in the Directory Service log. The error reports that the object cannot be updated and replication will not be accepted from the source until the issue is resolved. The information in the error includes the name, GUID, and source of the lingering object so that you can delete the object and determine whether additional lingering objects exist on the source. For this error to be logged, however, you must have modified the registry to implement strict replication consistency.

In both cases, you can delete the identified lingering object and then take steps to identify and remove all additional lingering objects from the outdated domain controller.

Sequence for Removing Lingering Objects

The process for removing lingering objects from an outdated writable domain controller involves several procedures that must be performed in sequence. After an error indicates the existence of a lingering object, use the following general sequence to remove the lingering object and determine whether there are other lingering objects on the source domain controller:

· Identify the domain controller that replicated the update to a lingering object. Use the information in event ID 1388 (Windows 2000 Server with SP2) or event ID 1084 (Windows 2000 Server with SP3) to identify the source domain controller.

· Disable outbound replication on the source domain controller.

· Delete the lingering object from the source domain controller.

· Compare the database contents of the outdated source domain controller and an up-to-date replication partner to determine whether the outdated source domain controller contains objects that do not exist on its replication partner.

· Identify the distinguished names of the objects that exist on the outdated domain controller but not on the replication partner.

· Examine metadata of the object to determine when it was created.

· Delete the objects that were created prior to disconnecting the domain controller.

· Restart outbound replication on the source domain controller.

Deletions of the lingering objects replicate to the other domain controllers. Any domain controller that is running Windows 2000 Server with SP2, and that does not have the object, logs event ID 1388. In this case, the missing object is revived as a tombstone, and replicates as such. The errors on domain controllers that do not have the object can be ignored; they will cease after the second replication cycle.

If you have domain controllers that are running Windows 2000 Server with SP3, you can set the registry to enforce strict replication consistency, which ensures that lingering objects do not replicate. For this reason, attempted replication of the deletions will not be accepted. You must delete lingering objects from only the outdated domain controller. For information about setting strict replication consistency for domain controllers that are running Windows 2000 Server with SP3, see “Managing Active Directory Installation and Removal” in this guide.

Procedures for Removing Lingering Objects from an Outdated Writable Domain Controller

Use the following process to identify and remove lingering objects after you have discovered an outdated domain controller. The initial step in the process varies according to the version of Windows 2000 Server that you are using. Procedures are explained in detail in the linked topics.

1. Identify and delete the initial occurrence of a lingering object, as follows:

For Windows 2000 Server with SP2:

a. Identify a revived lingering object and its replication source on a writable domain controller. Event ID 1388 provides the distinguished name of an object that has been updated on an outdated domain controller. The message also provides the GUID of the domain controller from which the update was replicated. Use the GUID to discover the name of the source domain controller. Repeat this process on each source domain controller until you identify a source domain controller that does not have the error. This domain controller is the outdated source domain controller.

b. Disable outbound replication on the outdated source domain controller.

c. Delete the object from the outdated source domain controller.

For Windows 2000 Server with SP3:

· Identify and delete a known non-replicated lingering object on an outdated domain controller, as identified in event ID 1084. The object and source domain controller are named in the error message.

2. Identify unknown lingering objects on an outdated domain controller. This procedure requires the following series of subprocedures to be performed sequentially:

a. Compare the directory databases of the outdated domain controller and the domain controller that received the initial replication error.

b. Identify the distinguished names of the objects that exist on the outdated domain controller but not on the partner domain controller.

Note

The results of this procedure identify only objects where the numbers of objects did not agree between domain controllers. If numbers match but an object of a class was added on one domain controller and a different object of the same class was deleted on the other, and these changes did not replicate, this test cannot identify these inconsistent objects.

3. On the outdated domain controller, view the replication metadata of objects that you identified in the previous procedure to determine whether they were created prior to the time the domain controller was disconnected or were created during the time that the domain controller was offline. If the newest date in the Org.Time/Date column is older than the date on which the domain controller was disconnected, the object is a lingering object.

4. On the outdated domain controller, delete the objects that were created prior to the date and time that the domain controller was disconnected.

5. Restart disabled outbound replication on the outdated domain controller (SP2 only).

6. Synchronize replication from the outdated domain controller to the partner domain controller to replicate the deletions. Use the connection object on the replication partner that shows the name of the outdated domain controller in the From Server column. This procedure results in error messages on domain controllers that do not have the objects, but these messages can be ignored and will cease by the second replication cycle.

Removing Lingering Objects from a Global Catalog Server

If you delete a lingering object on a writable domain controller, the object deletion replicates to all writable domain controllers in the domain as well as to all global catalog servers. However, if a global catalog server becomes outdated, lingering objects can potentially exist in a read-only replica on the global catalog server and nowhere else, in which case you cannot delete the object by the normal method. The recommended solution to this problem depends on the version of Windows 2000 Server that is running on the outdated global catalog server:

· Windows 2000 Server with SP2: Contact Microsoft Product Support Services.

· Windows 2000 Server with SP3: Use Ldp.exe to identify and delete the object from all global catalog servers that retain the object.

Causes for Lingering Objects on Global Catalog Servers

Excessively high replication load on a global catalog server, in combination with a short intersite replication interval, can result in updates not being replicated. Global catalog servers replicate read-only replicas of all domain directory partitions in the forest. The replication of read-only replicas has a lower priority than the replication of writable replicas. In addition, global catalog servers are often bridgehead servers, which adds to the replication load. If the replication load on global catalog servers acting as bridgehead servers is too high due to an extremely short replication interval, excessive numbers of concurrent outbound replication partners, or a combination of both, the replication queue can become backlogged. If the condition persists, read-only replicas can remain in the queue indefinitely. These conditions can result in lingering objects on a global catalog server.

If replication of a read-only replica is stalled or the domain controller is disconnected for longer than a tombstone lifetime, the deletion of an object from the corresponding writable directory partition can potentially expire without ever reaching the global catalog server. In this case, the only location of this object is in the read-only replica on the global catalog server.

As with writable domain controllers, a global catalog server that is not monitored for replication can potentially become outdated. When appropriate monitoring is in place and sensible intersite replication schedules are configured, global catalog servers are not susceptible to becoming outdated. For information about monitoring replication, see “Monitoring Active Directory” in this document. For information about scheduling replication, see “Managing Sites” in this document.

Indications that Lingering Objects Exist on a Global Catalog Server

The following events indicate that a lingering objects exists on a global catalog server:

· A deleted user or group account does not disappear from the Global Address List on Exchange servers.

· E-mail messages are not deliverable to a user whose Active Directory account appears to be current.

· A new user account or Exchange mailbox cannot be created because the object already exists, but you do not see the object in Active Directory.

· Searches that use attributes of an existing object find an object of the same name that has been deleted from the domain but remains in an isolated global catalog server.

Sequence for Removing Lingering Objects from a Global Catalog Server

To remove a lingering object from a global catalog server, you need an attribute value to use for the search to identify the object in the global catalog. For example, when you are trying to create a mailbox, user account, or other object in Active Directory, and error messages indicate that the object already exists, use the name of the object that you are trying to create. If you know that a deleted group or user name appears in the Global Address List, use that name.

Use the following general sequence of tasks to locate and remove a lingering object from a global catalog server:

· Use an LDAP search to establish the distinguished name and GUID of the duplicate (lingering) object.

· Use the distinguished name to identify the domain of the object.

· Identify a writable domain controller for that domain.

· Identify the GUID of the writable domain controller.

· Delete the object from the global catalog server. This procedure requires the preceding information.

· Repeat the previous steps for every object and global catalog server that is outdated.

When deleting an object that has child objects, you must delete the child object first, then delete the parent. You can tell from the distinguished name whether the object has parent objects.

Procedures for Removing a Lingering Object from a Global Catalog Server

Use the following procedures to identify and remove a read-only lingering object from a global catalog server that is running Windows 2000 Server with SP3. Procedures are explained in detail in the linked topics.

1. Establish the distinguished name and GUID of the object by searching the global catalog on an attribute that can uniquely identify the object. From the distinguished name, you can identify the domain by the DC= components.

2. Identify the GUID of a domain controller that has a writable replica of the domain of the lingering object.

3. Delete the lingering object from the global catalog server. In this procedure, use the GUID of the object and the GUID of the writable domain controller that you identify in procedures 1 and 2.

Managing Trusts

Trusts require little management. Trust relationships between domains establish a trusted communication path through which a computer in one domain can communicate with a computer in the other domain. Trust relationships allow users in the trusted domain to access resources in the trusting domain.

For example, where a one-way trust exists:

· A user who is logged on to the trusted domain can be authenticated to connect to a resource server in the trusting domain.

· A user can use an account in the trusted domain to log on to the trusted domain from a computer in the trusting domain.

· A user in the trusting domain can list trusted domain security principals and add them to groups and access control lists (ACLs) on resources in the trusting domain.

General Guidelines for Trusts

When you create a Windows 2000 domain in an existing Windows 2000 forest, a trust relationship is established automatically. These trust relationships are two-way and transitive, and they should not be removed.

However, three types of trusts must be created manually:

u· External trusts:

u· Trusts between a Windows 2000 domain and a Windows NT 4.0 domain.

u· Any trust between domains in different forests, whether both domains are Windows 2000 or one is Windows 2000 and the other Windows NT 4.0.

u· Shortcut trusts between two domains in the same forest.

u· Trust relationships between a Windows 2000 domain and a non‑Windows Kerberos realm. For more information about trusts between a Windows 2000 domain and a non-Windows Kerberos realm, see the Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability link on the Web Resources page at http://www.Microsoft.com/windows/reskits/webresources.

You might also need to manage trusts for the following reasons:

u· To remove a manually created trust.

u· To configure security identifier (SID) filtering to deny one domain the right to provide credentials for another domain. You can enable SID filtering for external trusts, that is, trusts between domains in different forests, or between a Windows 2000 and a Windows NT 4.0 domain.

Trust Management Tasks and Procedures

Table 1.20 shows the tasks and the procedures for managing trusts.

Table 1.20   Trust Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Create an external trust (between a Windows 2000 domain and a Windows NT 4.0 domain, or between domains in different forests).	§· Create a One-way Trust (MMC Method). §· Create a One-way Trust (Netdom.exe Method). §· Create a Two-way Trust (MMC Method). §· Create a Two-way Trust (Netdom.exe Method).	· Active Directory Domains and Trusts (Windows 2000) ‑Or‑ · Netdom.exe · User Manager for Domains (Windows NT 4.0)	As needed
Create a shortcut trust.	§· Create a One-way Trust (MMC Method). §· Create a One-way Trust (Netdom.exe Method). §· Create a Two-way Trust (MMC Method). §· Create a Two-way Trust (Netdom.exe Method).	· Active Directory Domains and Trusts ‑Or‑ · Netdom.exe	As needed
Remove a manually created trust.	§· Remove a manually created trust.	· Active Directory Domains and Trusts ‑Or‑ · Netdom.exe	As needed
Prevent unauthorized privilege escalation.	§· Configure SID filtering.	· Netdom.exe	As needed

Creating External Trusts

You create an external trust when you want to establish a trust relationship between Windows 2000 domains that are in different forests, or between a Windows 2000 domain and a Windows NT 4.0 domain. An external trust relationship has the following characteristics:

u· It is one-way. The trust must be established manually in each direction to create a two-way external trust relationship.

u· It is nontransitive.

If you upgrade a Windows NT 4.0 domain to a Windows 2000 domain, the existing trust relationships remain in the same state.

Methods for Creating the External Trust

u· Use the procedure Create a One-way Trust - MMC Method to create a trust where one domain trusts another to use its resources.

u· Use the procedure Create a One-way Trust - Netdom.exe Method to use the support tool Netdom.exe to create both sides of a one-way trust at once. You must provide credentials for both domains to use the Netdom.exe method.

u· Use the procedure Create a Two-way Trust - MMC Method first to create both portions configured in one domain, and then to create both portions configured in the other domain.

u· Use the procedure Create a Two-way Trust - Netdom.exe Method to use the support tool Netdom.exe to create both sides of the trust at once. You must provide credentials for both domains to use the Netdom.exe method.

Requirements

u· Credentials: Domain Admins

u· You can create the trust when you log on to the domain, or use the Run As command to create the trust for a different domain.

u· Tools: Active Directory Domains and Trusts or Netdom.exe (Support Tools).

Procedures for Creating External Trusts

You can create an external trust by using one of the following methods. Procedures are explained in detail in the linked topics.

1. Create a One-way Trust (MMC Method)

2. Create a One-way Trust (Netdom.exe Method)

3. Create a Two-way Trust (MMC Method)

4. Create a Two-way Trust (Netdom.exe Method)

Creating Shortcut Trusts

A shortcut trust relationship is a manually created trust that shortens the trust path to improve the efficiency of users who remotely log on. A trust path is a chain of multiple trusts that enables trust between domains that are not adjacent in the domain namespace. For example, if users in domain A need to gain access to resources in domain C, you can create a direct link from domain A to domain C through a shortcut trust relationship, bypassing domain B in the trust path.

A shortcut trust relationship has the following characteristics:

u· It can be established between any two domains in the same forest.

u· It must be established manually in each direction.

u· It is transitive.

Requirements

u· Credentials: Domain Admins

u· Tool: Active Directory Domains and Trusts

Procedures for Creating Shortcut Trusts

You can create a shortcut trust by using one of the following methods. Procedures are explained in detail in the linked topics.

1. Create a One-way Trust (MMC Method)

2. Create a One-way Trust (Netdom.exe Method)

3. Create a Two-way Trust (MMC Method)

4. Create a Two-way Trust (Netdom.exe Method)

Removing Manually Created Trusts

You can remove manually created trusts, but you cannot remove the default two-way transitive trusts between domains in a forest. It is particularly important to verify that you successfully removed the trusts if you are planning to re-create them.

Requirements

u· Credentials: Domain Admins

u· Tool: Active Directory Domains and Trusts or Netdom.exe.

Procedure for Removing Manually Created Trusts

You can remove a manually created trust by using one of the following methods. Procedures are explained in detail in the linked topics.

1. Remove a manually created trust by using the Active Directory Domains and Trusts snap-in.

2. Remove a manually created trust by using Netdom.exe.

Preventing Unauthorized Privilege Escalation

Security principals in Active Directory have an attribute called SIDHistory to which domain administrators can add users’ old SIDs. This is useful during the migration process because users can use their old SIDs to access resources, administrators do not need to modify ACLs on large numbers of resources. However, under some circumstances it is possible for domain administrators to use the SIDHistory attribute to associate SIDs with new user accounts, thereby granting themselves unauthorized rights.

You can configure SID filtering to prevent this type of attack. You might configure SID filtering under the following circumstances:

u· You have identified one or more domains in your enterprise where physical security is lax, or where the domain administrators are less well trusted.

u· You then isolate these less trustworthy domains by moving them to other forests. By definition, all domains within a forest must be trustworthy; if a domain is deemed less trustworthy than the others in the forest, it should not be a forest member. Once you have moved less trustworthy domains out of the forest, establish external trusts to these domains, and apply access control to protect resources. If you are still concerned about SID spoofing being used for privilege escalation, then apply SID filtering.

u· Do not apply SID filtering to domains within a forest, as this removes SIDs required for Active Directory replication, and causes authentication to fail for users from domains that are transitively trusted through the isolated domain.

Procedure for Preventing Unauthorized Privilege Escalation

Use the following procedures to configure SID filtering. Procedures are explained in detail in the linked topics.

1. Configure SID filtering.

2. Remove SID filtering.

Managing Sites

An Active Directory site object represents a collection of Internet Protocol (IP) subnets, usually constituting a physical Local Area Network (LAN). Multiple sites are connected for replication by site link objects.

Sites are used in Active Directory to:

· Enable clients to discover network resources (printers, published shares, domain controllers) that are close to the physical location of the client, reducing network traffic over Wide Area Network (WAN) links.

· Optimize replication between domain controllers.

Managing sites in Active Directory involves adding new subnet, site, and site link objects when the network grows, as well as configuring a schedule and cost for site links. You can modify the site link schedule, cost, or both, to optimize intersite replication. When conditions no longer require replication to a site, you can remove the site and associated objects from Active Directory.

Large hub-and-spoke topology management is beyond the scope of this documentation. For information about managing Active Directory branch office deployments that include more than 200 sites, see the “Active Directory Branch Office Guide Series” at http://www.microsoft.com/technet/win2000/win2ksrv/adguide/default.asp.

Using the SMTP intersite replication transport is beyond the scope of this documentation. For information about SMTP replication, see “Active Directory Replication” in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit and see the “Step-by-Step Guide to Setting up ISM-SMTP Replication.” To download this guide, see the Active Directory link on the Web Resources page at <A HREF="http://go.microsoft.com/fwlink/?linkid=291" TARGET="_blank">http://www.microsoft.com/windows/reskits/webresources</A>.

Automatic site coverage is a default condition for Windows 2000 domain controllers. Operations and guidelines documented in this guide are consistent with the enabling of automatic site coverage.

The KCC and Replication Topology

The Knowledge Consistency Checker (KCC) uses site link configuration information to enable and optimize replication traffic by generating a least-cost replication topology. Within a site, for each directory partition, the KCC builds a ring topology that minimizes the number of hops between domain controllers. Between sites, the KCC creates a spanning tree of all intersite connections. Therefore, adding sites and domains increases the processing that is required by the KCC. Before adding to the site topology, be sure to consider the guidelines discussed in “Adding a New Site” later in this document.

Significant changes to site topology can affect domain controller hardware requirements. For more information about domain controller hardware requirements, see “Domain Controller Capacity Planning” in “Best Practice Active Directory Design for Managing Windows Networks.” To download this guide, see the Active Directory link on the Web Resources page at <A HREF="http://go.microsoft.com/fwlink/?linkid=291" TARGET="_blank">http://www.microsoft.com/windows/reskits/webresources</A>.

Bridgehead Server Selection

By default, bridgehead servers are automatically selected by the intersite topology generator (ISTG) in each site. Alternatively, you can use Active Directory Sites and Services to select preferred bridgehead servers. However, it is recommended for Windows 2000 deployments that you do not select preferred bridgehead servers.

Selecting preferred bridgehead servers limits the bridgehead servers that the KCC can use to those that you have selected. If you use Active Directory Sites and Services to select any preferred bridgehead servers at all in a site, you must select as many as possible and you must select them for all domains that must be replicated to a different site. If you select preferred bridgehead servers for a domain and all preferred bridgehead servers for that domain become unavailable, replication of that domain to and from that site does not occur.

If you have selected one or more bridgehead servers, removing them from the bridgehead servers list restores the automatic selection functionality to the ISTG.

Site Management Tasks and Procedures

Table 1.21 shows the tasks and procedures for managing sites, as well as the tools and the recommended frequency for performing each task. After you configure sites, subnets, and site links for the initial deployment, most site management activity is limited to responding to changes in network conditions.

Table 1.21   Site Management Tasks and Procedures

Tasks	Procedures	Tools	Frequency
Add a new site.	· Create a site object. · Create a subnet object and associate it with the site. –or– · Associate an existing subnet object with the site. · Create a site link object, if appropriate. · Remove the site from a site link, if appropriate.	· Active Directory Sites and Services	As needed
Add a subnet to the network.	· Obtain the network address and subnet mask for the subnet. · Create a subnet object and associate it with a site.	· Active Directory Sites and Services	As needed
Link sites for replication.	· Determine the names of the sites you are linking. · Create a site link object. · Determine the ISTG role owner for a site. · Generate the replication topology on the ISTG, if appropriate.	· Active Directory Sites and Services	As needed
Change site link properties.	· Configure the site link schedule. · Configure the site link interval. · Configure the site link cost. · Determine the ISTG role owner for a site. · Generate the replication topology on the ISTG, if appropriate.	· Active Directory Sites and Services	As needed
Move a domain controller to a different site.	· Change the static IP address of the domain controller. · Create a delegation for the domain controller, if appropriate. · Verify that the IP address maps to a subnet and determine the site association. · Determine whether the server is a preferred bridgehead server. · Configure the domain controller to not be a preferred bridgehead server, if appropriate. · Move the server object to a different site.	· My Network Places · Active Directory Sites and Services · DNS snap-in	As needed
Remove a site.	· Determine whether the server object has child objects. · Delete the server object or objects from the site. · Delete the site link object, if appropriate. · Associate the subnet or subnets with a different site. –or– · Delete the subnet objects. · Delete the site object. · Determine the ISTG role owner for a site. · Generate the replication topology on the ISTG, if appropriate.	· Active Directory Sites and Services	As needed

Adding a New Site

Design teams or network architects might want to add sites as part of ongoing deployment. Although you typically create subnets to accommodate all address ranges in the network, you do not need to create sites for every location. Generally, sites are required for those locations that have domain controllers or other servers that run applications that depend on site topology, such as Distributed File System (DFS). When such locations are separated from other network locations by a WAN link, create a site object to optimize resource location, Active Directory replication, and domain controller location for clients.

When the need for a site arises, the design team typically provides details about the placement and configuration of site links for the new site, as well as subnet assignments or creation if subnets are needed.

KCC calculations for generating the intersite topology for a Windows 2000 forest can cause directory performance to suffer when the combined sites, site links, and domains exceed certain limits. When these limits are reached, follow the site administration guidelines on the Active Directory Branch Office Planning Guide link on the Web Resources page at <A HREF="http://go.microsoft.com/fwlink/?linkid=291" TARGET="_blank">http://www.microsoft.com/windows/reskits/webresources</A>.

As a general guideline, when any of the following conditions exist, consult your design team before adding a new site:

· An existing site is directly connected to more than 20 sites.

· A bridgehead server has more than 20 inbound connections.

· The forest has 200 or more sites.

Procedures for Adding a New Site

Use the following procedures to add a new site. Procedures are explained in detail in the linked topics.

1. Create a site object and add it to an existing site link.

2. Associate a range of IP addresses with the site, as follows:

· Create a subnet object or objects and associate them with the new site.

–or–

· Associate an existing subnet object with the new site.

3. Create a site link object, if appropriate, and add the new site and at least one other site to the site link.

4. If, while performing procedure 1, you added the new site to an existing site link temporarily in order to create the site, remove the site from that site link.

Adding a Subnet to the Network

If a new range of IP addresses is added to the network, create a subnet object in Active Directory to correspond to the range of IP addresses. When you create a new subnet object, you must associated it with a site object. You can either associate the subnet with an existing site, or create a new site first and then create the subnet and associate it with the new site. If you are going to create a new site for the new network segment, see “Adding a New Site.”

Procedures for Adding a Subnet

Use the following procedures to add a subnet. Procedures are explained in detail in the linked topics.

1. Obtain the network address and subnet mask for the new subnet.

2. Create a subnet object and associate it with the appropriate site.

Linking Sites for Replication

To link sites for replication, create a site link object in the IP transport container and add two or more sites to the link. Use a naming convention that includes the sites that you are linking. For example, if you want to link the site named Seattle to the site named Boston, you might name the site link SEA-BOS.

After you add two or more site names to a site link object, the bridgehead servers in the respective sites replicate between the sites according to the replication schedule, cost, and interval settings on the site link object. For information about modifying the default settings, see “Changing Site Link Properties.”

At least two sites must exist when you create a site link. If you are adding a site link to connect a new site to an existing site, create the new site first and then create the site link. For information about creating a site, see “Adding a New Site.”

Procedures for Creating a Site Link

Use the following procedures to link sites for replication. Procedures are explained in detail in the linked topics.

1. Determine the names of the sites you are linking.

2. Create a site link object in the IP container and add the appropriate sites to it.

3. Generate the intersite topology. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate replication topology generation immediately, use the following procedures to refresh the intersite topology:

a. Determine the ISTG role owner for the site.

b. Generate the replication topology on the ISTG.

Changing Site Link Properties

To control which sites replicate directly with each other and when, use the cost, schedule, and interval properties on the site link object.

These settings control intersite replication as follows:

· Schedule: The time during which replication can occur (the default setting allows replication at all times).

· Interval: The number of minutes between replication polling by intersite replication partners within the open schedule window (default is every 180 minutes).

· Cost: The relative priority of the link (default is 100). Lower relative cost increases the priority of the link over other higher-cost links.

Consult your design documentation for information about values to set for site link properties.

Procedures for Configuring Site Links

Use the following procedures to configure a site link. Procedures are explained in detail in the linked topics.

1. Configure the site link schedule to identify times during which intersite replication can occur.

2. Configure the site link interval to identify how often replication polling can occur during the schedule window.

3. Configure the site link cost to establish a priority for replication routing.

4. Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate intersite replication topology generation immediately, use the following procedures to refresh the topology:

a. Determine the ISTG role owner for the site.

b. Generate the replication topology on the ISTG.

Moving a Domain Controller to a Different Site

If you change the IP address or the subnet-to-site association of a domain controller after Active Directory is installed on the server, the server object does not change sites automatically. You must move it to the new site manually. When you move the server object, the Net Logon service on the domain controller registers DNS SRV resource records for the appropriate site.

TCP/IP Settings

When you move a domain controller to a different site, if an IP address of the domain controller is statically configured, then you must change the TCP/IP settings accordingly. The IP address of the domain controller must map to a subnet object that is associated with the site to which you are moving the domain controller. If the IP address of a domain controller does not match the site in which the server object appears, the domain controller must communicate over a potentially slow WAN link to locate resources rather than locating resources in its own site.

Prior to moving the domain controller, ensure that the following TCP/IP client values are appropriate for the new location:

· IP address, including the subnet mask and default gateway.

· DNS server addresses.

· WINS server addresses (if appropriate).

If the domain controller that you are moving is a DNS server, you must also:

· Change the TCP/IP settings on any clients that have static references to the domain controller as the preferred or alternate DNS server.

· Determine whether the parent DNS zone of any zone that is hosted by this DNS server contains a delegation to this DNS server. If yes, update the IP address in all such delegations. For information about creating DNS delegations, see “Performing Active Directory Post-Installation Tasks.”

Preferred Bridgehead Server Status

Before moving any server object, check the server object to see whether it is acting as a preferred bridgehead server for the site. This condition has ISTG implications in both sites, as follows:

· Site to which you are moving the server: If you move a preferred bridgehead server to a different site, it becomes a preferred bridgehead server in the new site. If preferred bridgehead servers are not currently in use in this site, the ISTG behavior in this site changes to support preferred bridgehead servers. For this reason, you must either configure the server to not be a preferred bridgehead server (recommended), or select additional preferred bridgehead servers in the site (not recommended).

· Site from which you are moving the server: If the server is the last preferred bridgehead server in the original site for its domain, and if other domain controllers for the domain are in the site, the ISTG selects a bridgehead server for the domain. If you use preferred bridgehead servers, always select more than one server as preferred bridgehead server for the domain. If after the removal of this domain controller from the site multiple domain controllers remain that are hosting the same domain and only one of them is configured as a preferred bridgehead server, either configure the server to not be a preferred bridgehead server (recommended), or select additional preferred bridgehead servers hosting the same domain in the site (not recommended).

Note

If you select preferred bridgehead servers and all selected preferred bridgehead servers for a domain are unavailable in the site, the ISTG does not select a new bridgehead server. In this case, replication of this domain to and from other sites does not occur. However, if no preferred bridgehead server is selected for a domain or transport (through administrator error or as the result of moving the only preferred bridgehead server to a different site), the ISTG automatically selects a preferred bridgehead server for the domain and replication proceeds as scheduled.

Procedures for Moving a Domain Controller to a Different Site

Use the following procedures to move a domain controller to a different site. Procedures are explained in detail in the linked topics.

1. Change the static IP address of the domain controller. This procedure includes changing all appropriate TCP/IP values, including preferred and alternate DNS servers, as well as WINS servers (if appropriate). Obtain these values from the design team.

2. Create a delegation for the domain controller, if appropriate. If the parent DNS zone of any zone that is hosted by this DNS server contains a delegation to this DNS server, use this procedure to update the IP address in all such delegations.

3. Verify that the IP address maps to a subnet and determine the site association to ensure that the subnet is associated with the site to which you are moving the server object.

4. Determine whether the server is a preferred bridgehead server.

5. If the server is a preferred bridgehead server in the current site and you do not want the server to be a preferred bridgehead server in the new site, configure the server to not be a preferred bridgehead server.

6. Move the server object to the new site.

Removing a Site

If domain controllers are no longer needed in a network location, you can remove them from the site and then delete the site object. Before deleting the site, you must remove domain controllers from the site either by removing it entirely or by moving it to a new location.

· To remove the domain controller, remove Active Directory from the server and then delete the server object from the site in Active Directory. For information about removing a domain controller, see “Decommissioning a Domain Controller.”

· To retain the domain controller in a different location, move the domain controller to a different site and then move the server object to the respective site in Active Directory. For information about moving a domain controller, see “Moving a Domain Controller to a Different Site.”

Domain controllers can host other applications that depend on site topology and publish objects as child objects of the respective server object. For example, when MOM or Message Queuing are running on a domain controller, these applications create child objects beneath the server object. In addition, a Message Queuing server that is not a domain controller and is configured to be a Message Queuing Routing Server creates a server object in the Sites container. Removing the application from the server automatically removes the child object below the respective server object. However, the server object is not removed automatically.

When all applications have been removed from the server (no child objects appear beneath the server object), you can remove the server object. After the application is removed from the server, a replication cycle might be required before child objects are no longer visible below the server object.

After you delete or move the server objects but before you delete the site object, reconcile the following objects:

· Subnet object or objects for the site IP addresses:

· If the addresses are being reassigned to a different site, associate the subnet object or objects with that site. Any clients using the addresses for the decommissioned site will thereafter be assigned automatically to the other site.

· If the IP addresses will no longer be used on the network, delete the corresponding subnet object or objects.

· Site link object or objects. You might need to delete a site link object, as follows:

· If the site you are removing is added to a site link containing only two sites, delete the site link object.

· If the site you are removing is added to a site link that contains more than two sites, do not delete this site link object.

Before deleting a site, obtain instructions from the design team for reconnecting any other sites that might be disconnected from the topology by removing this site. If the site you are removing is added to more than one site link, it might be an interim site between other sites that are added to this site link. Deleting the site might disconnect the outer sites from each other. In this case, the site links must be reconciled according to the instructions of the design team.

Procedures for Removing a Site

Use the following procedures to remove a site. Procedures are explained in detail in the linked topics.

1. Determine whether the server object has child objects. If a child object appears, do not delete the server object. If a domain controller has been decommissioned and one or more child objects appears below the server object, replication might not have completed. If replication has completed and child objects exist, do not delete the server object. Contact a supervisor.

2. Delete the server objects within the Servers container of the site that you are removing.

3. Delete the site link object, if appropriate. Obtain this information from the design team.

4. Associate the subnet or subnets with the appropriate site, if appropriate. If you no longer want to use the IP addresses associated with the subnet object or objects, delete the subnet objects. Obtain this information from the design team.

5. Delete the site object.

6. Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate intersite replication topology generation immediately, use the following procedures to refresh the topology:

a. Determine the ISTG role owner in the site.

b. Generate the replication topology on the ISTG.

Chapter Number 2

Troubleshooting Active Directory

Although troubleshooting any distributed system can be challenging and time-consuming, applying a structured methodology to Active Directory troubleshooting can help you quickly sort through the possible causes and reveal the root cause of any problem.

In This Chapter

Overview of Active Directory Troubleshooting

High-level Methodology for Troubleshooting Active Directory Problems

Troubleshooting High CPU Usage on a Domain Controller

Troubleshooting Active Directory–Related DNS Problems

Troubleshooting FRS

Troubleshooting Active Directory Replication

Troubleshooting Active Directory Installation Wizard Problems

Troubleshooting Directory Data Problems

Troubleshooting Windows Time Service Problems

Overview of Active Directory Troubleshooting

Active Directory® directory service is a distributed system that is comprised of many different services and depends on all of the services to function properly. The methodology presented in this chapter can ease the difficulties inherent in identifying the computers and services involved in problems you might be having, and help you isolate a problem to the core component.

In most cases, troubleshooting begins when you detect one of the following:

· An event reported in an event log.

· An alert generated by a monitoring system, such as Microsoft Operations Manager (MOM).

· A symptom reported by a user or noticed by IT personnel.

This chapter includes troubleshooting procedures for the events, monitoring alerts, and symptoms that either have the highest frequency of occurrence or that can cause the greatest problem in your organization. Specific sections for each Active Directory service also include troubleshooting procedures for error messages generated by some tools that you might use in the troubleshooting process.

Responding to Events

When responding to events in the event logs, first determine the source that is listed in the event log, such as the Net Logon service or the File Replication service (FRS). Table 2.1 shows the event source and IDs, and references the troubleshooting sections for events that occur most frequently or that cause problems with the highest severity. If Table 2.1 does not include the event ID that you are looking for, search for it in the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

Table 2.1   Active Directory Events Reference

Event Source	Event ID	Reference
FRS	13508, 13509, 13512, 13522, 13567, 13568	See “Troubleshooting FRS.”
Netlogon	5774, 5775, 5781, 5783, 5805	See “Troubleshooting Active Directory–Related DNS Problems.”
NTDS	1083, 1265, 1388, 1645	See “Troubleshooting Active Directory Replication Problems.”
UserEnv	1085	See “Troubleshooting Active Directory Replication Problems.”
W32Time	13, 14, 52-56, 60-64	See “Troubleshooting Windows Time Service Problems.”

Responding to Monitoring Alerts

As a best practice, use a comprehensive monitoring system for your environment. The alerts that monitoring systems generate vary. Table 2.2 shows some common alerts generated by Microsoft Operations Manager (MOM) with the Active Directory Management Pack (ADMP) installed and points you to the appropriate references for troubleshooting information.

If you are using a different monitoring system, look for the alert that most closely matches the alert generated by your system. If you do not find a monitoring alert in this table that you need information about, view the event logs and troubleshoot related error events that you find, or refer to further troubleshooting instructions in the section in this guide that most closely matches the problem reported.

Table 2.2   Active Directory Monitoring Alerts Reference

Monitoring Alert	Description	Reference
A domain controller has received a significant number of new replication partners.	This is normal when a computer is in the process of becoming a global catalog server or bridgehead server, or when new domains or domain controllers are added to the environment. Abnormal causes of this alert include replication or site link problems.	See “Troubleshooting Active Directory Replication Problems” for replication troubleshooting procedures. See “Managing Sites” for recommendations and procedures for establishing and verifying sites and site links.
Active Directory Essential Services has detected…	This is a high priority alert, because it indicates that the domain controller is unusable for the reason specified in the error.	If the alert indicates that a service is not running, restart the service. If the alert indicates a SYSVOL problem, see “Troubleshooting FRS” or “Managing SYSVOL” for further troubleshooting procedures or recommendations. If the alert indicates that the domain controller is not advertising, see “Troubleshooting Active Directory–Related DNS Problems.”
Active Directory global catalog search failed.	This is a high priority alert, because if a global catalog server cannot be reached, users will not be able to log on, and Exchange’s address book will not function.	Verify that this is a global catalog server. See “Verifying Server Health” to ensure the server is functioning properly.
Active Directory - lost objects warning.	A large number of objects are in the LostAndFound container.	See “Troubleshooting Directory Data Problems.”
Active Directory replication is occurring slowly.	The monitoring system has determined that replication times are exceeding set thresholds.	If necessary, see “Managing Sites” for recommendations on setting replication schedules or site topology configuration. You can also change the threshold if you are satisfied with the current schedule.
Failed to ping or bind to the <operations master> role holder.	The destination server might not be functioning, or there might not be network connectivity.	See “Verifying Server Health” and “Verifying Network Path.” If necessary, see “Managing Operations Masters” to determine if it is appropriate to seize the role. If the outage is expected, see “Managing Operations Masters” to transfer the role before the outage to avoid this error.
High CPU alert.	An application or service is consuming an inordinate amount of CPU.	See “Troubleshooting High CPU Usage on a Domain Controller.”
Replication is not occurring — all AD replication partners failed to synchronize.	Short term connectivity problems can be expected, but extended failures indicate a problem. Investigate any problem that persists for more than a few hours.	See “Troubleshooting Active Directory Replication Problems.”
Time skew detected.	The system time on the servers indicated in the alert is not synchronized.	See “Troubleshooting Windows Time Service Problems.”

Responding to Symptoms

If you are troubleshooting Active Directory based on symptoms reported by users or noticed by IT personnel, you need to perform some preliminary troubleshooting steps to isolate the cause of the problem. See “High-Level Methodology for Troubleshooting Active Directory Problems” in this guide for information about how to iterate the troubleshooting process until you have found the root cause and resolved the problem.

If you have already determined the most likely source or cause of the problem, you can refer to the appropriate section in this guide, such as “Troubleshooting High CPU Usage on a Domain Controller” or “Troubleshooting Active Directory Replication Problems.” Each section contains additional troubleshooting steps that allow you to further isolate the problem.

Prerequisites for Troubleshooting Active Directory

Before you begin troubleshooting Active Directory, ensure that you establish problem tracking prerequisites, review information about your IT environment, and become familiar with Active Directory concepts and services.

Problem Tracking Prerequisites

Have the following mechanisms in place to ensure timely problem detection, handling, and resolution:

· Service desk (or help desk)

· Incident and problem management processes

· Continuous monitoring software

For more information about implementing a service desk and incident and problem management processes within your organization, see the Microsoft Operations Framework (MOF) link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources. For more information about monitoring Active Directory, see “Monitoring Active Directory” in this guide.

Information About Your IT Environment

Ensure that the personnel performing Active Directory troubleshooting can easily access the following types of documentation:

· Active Directory configuration, including replication-related configuration documentation.

· Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and IP configurations.

· Application and service documentation (such as Exchange).

· Administrative model.

· Server placement and configurations.

· Change management logs.

Active Directory Concepts and Services

Ensure that the personnel performing the troubleshooting have at least a basic understanding of Active Directory concepts and services.

_{Active Directory Concepts}

Active Directory concepts include the following areas:

· Name resolution, including both DNS and NetBIOS name resolution with broadcasts, LMHOSTS files, and Windows Internet Name Service (WINS).

· Replication (including Microsoft® Windows 2000 Server native mode and Microsoft® Windows NT® 4.0 emulation).

· Time synchronization.

· Group Policy and File Replication service (FRS).

· Core Active Directory, including an understanding of the global catalog, domains, and forests.

· Authentication (both Kerberos authentication and LAN Manager).

· Active Directory Microsoft Management Console (MMC) snap-ins and Active Directory-related tools (including operating system, Support, and Resource Kit tools).

_{Active Directory Services}

To discover the root cause of problems with Active Directory, ensure that the personnel performing troubleshooting understand common Active Directory operations like replication and password change and how the following processes and role holders are involved in these operations:

· Operations master roles (including PDC emulator, relative identifier (RID) master, domain naming master, schema master, and infrastructure master).

· Key Distribution Center (KDC).

· Knowledge Consistency Checker (KCC).

· Intersite Topology Generator (ISTG).

· Time Reference Server (TRS).

Because Active Directory interacts with external services and protocols, such as TCP/IP for the transport protocol, DNS for name resolution, and FRS for file replication of Group Policy objects and logon scripts, accurately determining the cause of a problem and applying a solution becomes more complex. Effective troubleshooting requires a thorough knowledge of these and other protocols, as well as the diagnostic tools associated with each protocol.

For more information about Active Directory, networking protocols, and tools, see the Microsoft® Windows® 2000 Server Resource Kit. You can obtain additional information by searching Microsoft.com and TechNet, or by taking advantage of MCSE training classes and books.

Tools for Troubleshooting Active Directory

Table 2.3 lists the tools that you can use to troubleshoot Active Directory, where the tools are found, and a brief description of the purpose of the tool.

For information about installing the Windows 2000 Support Tools and the Windows 2000 Administrative Tools Pack, see Windows 2000 Server Help.

Table 2.3   Tools Used to Troubleshoot Active Directory

Tool	Location	Function
Active Directory Domains and Trusts snap-in	Windows 2000 Administrative Tools Pack	Administer domain trusts, add user principal name suffixes, and change the domain mode.
Active Directory Sites and Services snap-in	Windows 2000 Administrative Tools Pack	Administer the replication of directory data.
Active Directory Users and Computers snap-in	Windows 2000 Administrative Tools Pack	Administer and publish information in the directory.
ADSI Edit, MMC snap-in	Windows 2000 Support Tools	View, modify, and set access control lists (ACLs) on objects in the directory.
Backup Wizard	Windows 2000 operating system tool	Back up and restore data.
Control Panel	Windows 2000	View and modify computer, application, and network settings.
Dcdiag.exe	Windows 2000 Support Tools and Windows 2000 Server Resource Kit	Analyze the state of domain controllers in a forest or enterprise; assist in troubleshooting by reporting any problems.
DNS snap-in	Windows 2000 Administrative Tools Pack	Manage DNS.
Dsastat.exe	Windows 2000 Support Tools	Compare directory information on domain controllers and detect differences.
Event viewer	Windows 2000 Administrative Tools Pack	Monitor events recorded in event logs.
Ipconfig.exe	Windows 2000 operating system tool	View and manage network configuration.
Ldp.exe	Windows 2000 Support Tools	Perform Lightweight Directory Access Protocol (LDAP) operations against Active Directory.
Linkd.exe	Windows 2000 Server Resource Kit	Create, delete, update, and view the links that are stored in junction points.
MMC	Windows 2000	Create, save, and open administrative tools (called MMC snap-ins) that manage hardware, software, and network components.
Netdiag.exe	Windows 2000 Server Resource Kit and Windows 2000 Support Tools	Check end-to-end network connectivity and distributed services functions.
Netdom.exe	Windows 2000 Support Tools	Allow batch management of trusts, joining computers to domains, and verifying trusts and secure channels.
Net use, start, stop, del, copy, time	Windows 2000 operating system tool	Perform common tasks on network services, including stopping, starting, and connecting to network resources.
Nltest.exe	Windows 2000 Support Tools	Verify that the locator and secure channel are functioning.
Ntdsutil.exe	Windows 2000 operating system tool	Manage Active Directory, manage single master operations, remove metadata.
Ntfrsutl.exe	Windows 2000 Server Resource Kit	View and manage FRS configuration.
Performance Monitor	Windows 2000 operating system tool	View system performance data, performance logs and alerts, and trace log files.
Pathping.exe	Windows 2000 operating system tool	Trace a route from a source to a destination on a network, show the number of hops, and show packet loss.
Ping.exe	Windows 2000 operating system tool	Verify network connectivity.
Regedit.exe	Windows 2000 operating system tool	View and modify registry settings.
Repadmin.exe	Windows 2000 Support Tools	Verify replication consistency between replication partners, monitor replication status, display replication metadata, and force replication events and topology recalculation.
Replmon.exe	Windows 2000 Support Tools	Display replication topology, monitor replication status, and force replication events and topology recalculation.
Secedit.exe	Windows 2000 operating system tool	Manage Group Policy settings.
Services snap-in	Windows 2000 Administrative Tools Pack	Start, stop, pause, or resume system services on remote and local computers, and configures startup and recovery options for each service.
Setspn.exe	Windows 2000 Support Tools	Manage security principal names (SPNs).
Task Manager	Windows 2000	View processes and performance data.
Terminal Services	Windows 2000	Access and manage computers remotely.
W32tm	Windows 2000 operating system tool	Manage Windows Time Service.
Windows Explorer	Windows 2000	Access files, Web pages, and network locations.

High-level Methodology for Troubleshooting Active Directory Problems

Your entry point into troubleshooting an Active Directory problem might be as straightforward as receiving an event in an event log or an alert from a monitoring system. If the event or alert specified the components that are involved in the problem, you can start troubleshooting the process or event by referring to the appropriate section later in this guide.

However, if you are responding to a user call or a symptom noticed by IT personnel, you need to isolate the problem. You might also need to use the process in this section if previous troubleshooting efforts for an event or alert did not solve the problem. There is a possibility that you are not troubleshooting the correct combination of components.

In any case, you need to be familiar with the high-level methodology that follows for troubleshooting Active Directory. This helps you to isolate the problem to the correct components — or identify a different set of components if necessary.

Figure 2.1 shows the process for troubleshooting Active Directory.

Figure 2.1   Troubleshooting Active Directory

Documenting the Problem

Documenting the problem can reduce misunderstandings and help you resolve issues more quickly. It provides an accurate history that facilitates vendor involvement when necessary. This history also helps in the problem management process. If a particular problem keeps occurring, you can use past incident histories to identify and resolve the problem.

How you begin to document the problem depends on whether you are using a monitoring system, which is a best practice for Active Directory operations. If you are not using a monitoring system, all of your help desk tickets will be generated when a dissatisfied user logs a complaint. At this point, you are reactively troubleshooting, and the problem is more urgent. Due to the nature of reactive problem-solving, you might experience a service disruption at a significant cost. It is important to use a monitoring system to avoid these costs.

If you are following the best practices for operations and are using a monitoring system, usually the monitoring system proactively alerts you before an issue escalates to a service outage. A monitoring system is also likely to indicate the most common ways to resolve the problem. If you are alerted to a problem by the monitoring system, open a new help desk ticket and document all information raised by the alert, including the suggested remedies. Collect as much supporting information from the monitoring system as possible, including other alerts occurring on the same computer or other computers and services that might also be involved in the problem.

Then open a problem ticket for the customer call and verify that you have enough information to proceed. Typically, you need information such as:

· Date and time of occurrence.

· Error message number and text.

· Client information, including:

· Computer name for the client.

· User ID being used when the problem occurred.

· TCP/IP configuration.

· List of DNS servers that that client is configured to use.

· Operating system version, service pack, and any hot fixes.

· Server information, including:

· Computer name for the server.

· TCP/IP configuration.

· Operating system version, service pack, and any hot fixes.

· Network information, including:

· Domain name of the client.

· Domain name of the server.

· Application name and related settings.

· Service involved in the problem, such as network BIOS (NetBIOS), DNS, Server Message Block (SMB), and Lightweight Directory Access Protocol (LDAP).

In addition, identify whether:

· The problem is repeatable. If so, include the steps taken to reproduce the problem.

· Others are having the same problem.

· Help desk is able to duplicate and verify the issue. Include any troubleshooting steps already taken by the help desk, such as using Ping to verify network connectivity to the client or server.

Important

If the problem was not reported by the monitoring system, first open a new problem ticket to correct the gap in your monitoring coverage and then communicate the failure to the appropriate personnel. Information derived from troubleshooting this problem can provide the monitoring or problem management team with valuable insight to help detect and potentially prevent this problem in the future.

For more information about problem tickets, see the Microsoft Operations Framework (MOF) link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

Identifying the Components Involved

Identify the specific components that are involved in the problem, including the clients, network paths, servers, and services. Taking time to properly identify the machines and the actual protocols or services involved minimizes the risk of wasting significant time trying to solve the wrong problems on the wrong computers. The information you obtained while documenting the problem is a good starting point, but the problem might require additional investigation to ensure that you have identified the correct components.

Note

When troubleshooting Active Directory, remember that the client is the computer that makes the request and the server is the computer that responds to the request. Thus, computers running Microsoft® Windows 2000® Professional or Microsoft® Windows 2000 Server can be either clients or servers, depending on whether they are initiating or responding to a request.

Identifying the right components can be easy, such as when a workstation makes an LDAP call to a domain controller. However, it can also be much more complex, such as when a workstation that issues a net use command to a file server receives an “Access Denied” error message.

In this last case, the workstation is clearly the client because it initiated the request. The other most apparent components (server and service) involved are the file server that received the request, and the SMB Service (the file and print access protocol used by Windows 2000). However, an entirely different server and service might also be causing the problem. Consider the problems that can occur when connecting to the server:

· DNS or WINS might not return the correct IP address for the intended server to the client. This indicates a name resolution problem, which involves a different server and service.

· If the client is using Kerberos authentication as the authentication protocol, the Key Distribution Center (KDC) could be returning an error. This might indicates a time synchronization problem, which involves the KDC and the Windows Time Service.

Know the required steps for all of the protocols and services to function successfully, and be familiar with the common breaking points for each step.

Verifying Client Health

Because all client/server communications begin with the client issuing a request, start the troubleshooting process by verifying the health of the client computer that you identified in the previous step. The client must be correctly configured, connected to the network, and functioning properly. To verify the client health, perform the following tests:

· Verify that the client is connected to the local area network (LAN). Verify that network cables and hubs are firmly connected, and that any status indicators on network adapters and hubs are reporting activity.

· Use Performance Monitor to ensure that the client’s CPU usage is not too high.

· Verify network configuration for the client. Verify that the client’s IP configuration settings, including DNS and WINS settings, are correct. Resolve any problems before continuing.

Client health problems are generally simple to fix. If you find a problem at this point, correct it before proceeding.

For more information about troubleshooting client health problems, see the Operations Guide of the Microsoft® Windows 2000 Server Resource Kit. For more information about troubleshooting networking problems, see the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit.

Verifying Network Path

Verify that the network path between the client and server is properly working. Although the problem ticket might indicate that the help desk was able to reach the server, the client is most likely on a different network segment, so verify the network path again from the client. You can either perform the following tests at the client, or use Terminal Services or Remote Assistance from your current location to issue the commands from the client. Perform the following tests:

· Verify network configuration. Ensure that the IP configuration is what it should be, according to your records. Verify network connectivity between the client and the server by using the IP address of each computer. If connectivity is a problem, open a new problem ticket as described earlier. Perimeter firewalls, IPSec, network address translation (NAT) between the client and server, or personal firewalls like those included in Windows XP Professional can cause connectivity problems.

· If you cannot verify that the server received a request, or that the client received the response, use Network Monitor (NetMon) to perform a trace at the client and server. For more information about using Network Monitor, see “Monitoring Network Performance” in the Operations Guide of the Windows 2000 Server Resource Kit.

For more information about troubleshooting network problems, see the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit.

Verifying Server Health

To verify server health, perform the same verification tests on the server that you do on the client, to make sure that the server is configured correctly, connected to the network, and functioning properly. Perform the following steps:

· Verify that the server is connected to the LAN. Verify that network cables and hubs are firmly connected, and that any status indicators on network adapters and hubs are reporting activity.

· Verify network configuration. Verify that IP configuration settings, including DNS and WINS settings, are correct. Resolve any problems before continuing.

· Verify network connectivity. If any of the Ping or Pathping tests fail, see “TCP/IP Troubleshooting” in the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit.

For more information about troubleshooting server health problems, see the Operations Guide of the Windows 2000 Server Resource Kit. For more information about troubleshooting networking problems, see the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit.

Verifying Service Health

For the service that you have identified, verify that the:

· Service is installed properly on the server.

· Service is running.

· User has permissions to make the request.

In addition, view the service event log (typically, the application event log). If you find any warning or error events in the event log, determine the source and refer to the corresponding section in this guide for further troubleshooting procedures. If the event is not discussed in this guide, search the Microsoft Knowledge Base. To search the Microsoft Knowledge Base, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

For more information about troubleshooting service health problems, see the Operations Guide of the Windows 2000 Server Resource Kit.

Iterate the Troubleshooting Process

If the components that you initially identified do not reveal the root cause of the problem, you must identify additional components involved in the problem. Identify the next client, server, or service that might be involved in the problem and verify the health of each of those components until you reach the actual source of the problem.

You might need to iterate the process for troubleshooting Active Directory on several different components before you successfully identify the root cause. In this case, you must “walk the chain,” or repeat the troubleshooting process on each component that might be involved in the problem. Consider the following example, where you must iterate the troubleshooting process to identify the correct components.

A company has four domain controllers (DC1, DC2, DC3, and DC4). DC1 replicates to DC2, DC2 replicates to DC3, and DC3 replicates to DC4 (this is referred to as transitive replication). An administrator adds a user to Active Directory at DC1. Several hours later, the change still has not replicated to DC4. You initially identify DC3 and DC4 as the client and server involved. Your troubleshooting indicates that DC3 did not replicate the change to DC4. After verifying the health of the client, the network, the server, and replication, you determine that they are working properly. You must then iterate the troubleshooting process, but with the next link in the chain: DC2 and DC3. If this pair is working properly, then you need to verify DC1 and DC2.

Applying a structured approach to the troubleshooting process helps you methodically find the root cause of any distributed systems problem, regardless of the client, server, or service involved.

Troubleshooting High CPU Usage on a Domain Controller

If your monitoring system reports high CPU usage on a domain controller, or if you noticed high CPU usage while verifying the health of a domain controller, follow the troubleshooting process in this section. Figure 2.2 shows the high-level process for troubleshooting high CPU usage on a domain controller. This high-level process for troubleshooting high CPU usage on a domain controller helps you determine the cause of high CPU usage and leads to more detailed troubleshooting tasks.

Figure 2.2   Troubleshooting High CPU Usage on a Domain Controller

Troubleshooting High CPU Usage by Processes

Figure 2.3 shows the process for troubleshooting processes or services that cause high CPU usage.

Figure 2.3   Troubleshooting High CPU Usage by Processes

Procedures for Troubleshooting Services that Consume High CPU

1. Using Task Manager, determine whether high CPU usage is caused by Lsass.exe. If it is, go to the next step in the flowchart for troubleshooting high CPU usage on a domain controller, “Troubleshooting High CPU Usage on a PDC Emulator.” If high CPU usage is not caused by Lssas.exe, , continue with the following steps.

2. In Task Manager, determine which service is causing the problem.

3. If the problem is caused by backup or virus scan software, wait for the service to complete, and consider rescheduling the service for nonpeak usage hours. If possible, change configuration settings on the software to optimize CPU usage.

4. If another service is consuming high CPU, refer to the product documentation to troubleshoot that service.

Troubleshooting High CPU Usage on a PDC Emulator

If Lsass.exe is causing high CPU usage, determine if the domain controller is the PDC emulator. If it is, follow the process shown in Figure 2.4 for troubleshooting high CPU usage on a PDC emulator. If the domain controller is not the PDC emulator, go to the next step in the flowchart (Figure 2.4) for troubleshooting high CPU usage on a domain controller, “Troubleshooting High CPU Usage on a Global Catalog Server.”

Figure 2.4   Troubleshooting High CPU Usage on a PDC Emulator

Procedures for Troubleshooting High CPU Usage on a PDC Emulator

1. To determine whether the domain controller is a PDC emulator, view the current operations master role holders. If it is a PDC emulator, continue with the following steps.

2. Use the procedure to transfer the domain-level operations master roles to transfer the PDC emulator role to another domain controller.

3. If the problem still exists on the original server after transferring the PDC emulator role, see “Troubleshooting Server-Related High CPU Usage” in this guide.

4. If the problem still exists on the PDC emulator in its new location, determine whether account lockout policy is defined on this domain.

If account lockout is defined:

a. Confirm that all of the available patches are installed. If needed, contact Microsoft Product Support Services for this information.

b. Enable auditing on the PDC emulator. Find and remove any bad service accounts.

5. If you are using Systems Management Server (SMS), ensure that you have installed the most current SMS service packs.

6. If you have Windows NT 4.0–based BDCs and clients that are running Windows 2000 Professional or Windows XP Professional, perform the following tasks:

a. In Performance Monitor, examine the “logon total” and “logon/sec” counters for the server object under System Monitor. Do this on different domain controllers in your environment, especially on subnets that contain both Windows 2000–based and Windows NT 4.0–based domain controllers. Compare these numbers on the different domain controllers to determine if any Windows 2000–based domain controller is overloaded with a large number of authentication requests.

b. Member computers that are running Windows 2000 and Windows XP authenticate exclusively with Active Directory domain controllers in a domain once the domain controllers are discovered by the member computers. If a Windows 2000–based domain controller is overloaded because the number of upgraded domain controllers in the domain is not yet sufficient to withstand requests from all upgraded clients, you can alleviate the problem by adding Windows 2000–based domain controllers.

If necessary, configure Windows NT 4.0 emulation for each Windows 2000–based domain controller in order to stop the overloading effect until enough domain controllers have been upgraded. Rejoin the clients that have discovered up-level domain controllers to the domain. During your upgrade process, first upgrade domain controllers in locations with large populations of clients that are running Windows XP and Windows 2000. You also need to rejoin all Windows 2000–based and Windows XP–based domain members. In the rejoin procedure, specify a NetBIOS name for the domain. Until the domain members are rejoined, they cannot contact any domain controllers in the domain.

c. Configure Windows NT 4.0 emulation for some computers. You can configure computers that run Windows 2000 Service Pack 2 (SP2) or later to inform domain controllers that are running in Windows NT 4.0 emulation mode to not use Windows NT 4.0 emulation mode when they respond to requests from those computers.

7. If you are still experiencing problems, see “Reducing the Workload on the PDC Emulator” in this guide for more information about changing DNS weight or priority registry settings to reduce the workload for the PDC emulator.

Troubleshooting High CPU Usage on a Global Catalog Server

If Lsass.exe is causing high CPU usage on a domain controller that is not the PDC emulator, determine if the domain controller is also a global catalog server. If it is, follow the process shown in Figure 2.5 for troubleshooting high CPU usage on a global catalog server. If the domain controller is not a global catalog server, return to the next step in the high-level flowchart earlier in this section for troubleshooting high CPU usage on a domain controller.

Figure 2.5   Troubleshooting High CPU Usage on a Global Catalog Server

Procedures for Troubleshooting High CPU Usage on a Global Catalog Server

1. Determine whether the domain controller is a global catalog server. If it is, continue with the following steps.

2. See “Managing Global Catalog Servers” in this guide for background information and prescriptive guidance about global catalog servers. If you do not have enough global catalog servers in your environment, add a global catalog server.

3. Determine whether this is a bridgehead server. If Intersite Messaging (ISM) is off, start ISM. If necessary to manage a large number of connections, configure additional bridgehead servers.

Troubleshooting High CPU Usage Caused by Excessive Client Load

If Lsass.exe is causing high CPU usage on a domain controller that is not a PDC emulator or a global catalog server, disconnect the network cable. If CPU usage remains high after disconnecting the network cable, return to the next step in the flowchart for troubleshooting high CPU usage on a domain controller, “Troubleshooting Server-Related High CPU Usage.” If CPU usage is at or near 0% after disconnecting the network cable, follow the process shown in Figure 2.6 for troubleshooting high CPU usage caused by excessive client loads.

Figure 2.6   Troubleshooting High CPU Usage Caused by Excessive Client Load

Procedures for Troubleshooting Client Load-Related High CPU Usage

1. Review Best Practice Active Directory Deployment for Managing Windows Networks to determine proper hardware configuration. If your hardware is not adequate, resize the server. To review the best practice guidelines, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresourcesSearch under “Planning & Deployment Guides” and download Best Practice Active Directory Deployment for Managing Windows Networks.

2. Verify network configuration and ensure that the DNS settings are correct. Ensure that the DNS weight and priority registry settings that are set for load balancing are correct.

3. Use Adperf.exe to determine the problem.

a. If Adperf reveals searches that are consuming high CPU, turn on inefficient LDAP queries logging to identify a bad application or indexing.

b. If Adperf shows that a small set of clients is causing a high server load, troubleshoot the clients. An application problem is most likely causing the high CPU usage.

c. If Adperf shows that a small set of users is causing a high server load, determine what actions they are performing to cause the load.

4. If you have Windows NT 4.0 BDCs and Windows 2000 Professional or Windows XP Professional clients, do the following:

a. Configure Windows NT 4.0 emulation. If a Windows 2000–based domain controller is overloaded because the number of upgraded domain controllers in the domain is not yet sufficient to withstand requests from all upgraded clients, and if it is not already configured for Windows NT 4.0 emulation mode, configure the domain controller for Windows NT 4.0 emulation in order to stop the overloading effect until enough domain controllers have been upgraded. During your upgrade process, first upgrade domain controllers in locations with large populations of clients that are running Windows XP and Windows 2000. You also need to rejoin all Windows 2000–based and Windows XP–based domain members. In the rejoin procedure, specify a NetBIOS name for the domain. Until the domain members are rejoined, they cannot contact any domain controllers in the domain.

b. Modify Windows NT 4.0 emulation for some computers. You can configure computers that run Windows 2000 SP2 to inform domain controllers that are running in Windows NT 4.0 emulation mode to not use it when they respond to requests from those computers.

5. If this is a sudden increase in CPU usage, reconfigure or resize the server.

Troubleshooting Server-Related High CPU Usage

If CPU usage on the domain controller remains high after disconnecting the network cable, follow the process shown in Figure 2.7 for troubleshooting high CPU usage caused by problems on the server.

Figure 2.7   Troubleshooting Server-Related High CPU Usage

Procedures for Troubleshooting Server-Related High CPU Usage

1. Enable Active Directory diagnostic event logging for garbage collection and security descriptor propagator (SDProp). If the number of security suboperations per second is greater than zero, wait for the process to complete. Depending on the number of objects, the amount of time it takes to complete can vary.

2. Use Adperf.exe to determine the problem.

3. Either determine what process is causing the problem, or resize the server if inadequate hardware resources are causing the problem.

Troubleshooting Active Directory–Related DNS Problems

Active Directory functionality depends on the proper configuration of the DNS infrastructure. This includes the following:

· DNS client configuration, including domain controllers, domain members, and other computers.

· DNS server and zone configuration and proper delegations in parent DNS zones.

· Presence of DNS domain controller locator records.

Table 2.4 shows the DNS records that are required for proper Active Directory functionality.

Table 2.4   Required DNS Records

Mnemonic	Type	DNS Record	Requirements
Pdc	SRV	_ldap._tcp.pdc._msdcs.<DnsDomainName>	One per domain
GC	SRV	_ldap._tcp.gc._msdcs.<DnsForestName>	At least one per forest
GcIpAddress	A	_gc._msdcs.<DnsForestName>	At least one per forest
DsaCname	CNAME	<DsaGuide>._msdcs.<DnsForestName>	One per domain controller
Kdc	SRV	_kerberos._tcp.dc._msdcs.<DnsDomainName>	At least one per domain
Dc	SRV	_ldap._tcp.dc._msdcs.<DnsDomainName>	At least one per domain
	A	<DomainControllerFQDN>	One per domain controller (domain controllers that have multiple IP addresses can have more than one A resource record)

Following the best practices recommendations regarding DNS configuration from the beginning of the deployment is key for successful Active Directory deployment and operations. For more information about best practices for Active Directory design and deployment, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresourcesSearch under “Planning & Deployment Guides” and download Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks.

For comprehensive information about troubleshooting DNS problems, see “Windows 2000 DNS” in the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit.

For more information about troubleshooting WINS name resolution problems, see “Windows Internet Name Service” in the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit. For an online version of this book, see http://www.microsoft.com/windows2000/reskit.

Table 2.5 shows common events and symptoms that indicate DNS problems and points to sections where solutions can be found.

Table 2.5   Netlogon Events that Indicate DNS Problems

Event or Symptom	Root Cause	Solution
Netlogon Event ID 5774	The domain controller cannot dynamically register DNS records that advertise its availability as a domain controller.	Troubleshoot domain controller locator DNS records registration failure.
Netlogon Event ID 5775	The domain controller cannot dynamically register DNS records that advertise its availability as a domain controller.	Troubleshoot domain controller locator DNS records registration failure.
Netlogon Event ID 5781	The domain controller cannot dynamically register DNS records that advertise its availability as a domain controller.	Troubleshoot domain controller locator DNS records registration failure.
Netlogon Event ID 5783	The source server listed in the error message was unable to complete a remote procedure call (RPC) call to the destination server. Most commonly, this means that either the source server could not locate the server in DNS or the RPC interface on the destination server is not working.	If the source server could not locate the server in DNS, troubleshoot Active Directory replication failure due to incorrect DNS configuration. If this is not a DNS problem, troubleshoot RPC problems.
Active Directory Installation Wizard failed because it was unable to locate a domain controller	In order to add a server to an existing forest, the Active Directory Installation Wizard must be able to find a domain controller in the domain or the forest.	Troubleshoot Active Directory Installation Wizard failure to locate domain controller.
Unable to join a domain	The failure might be due to being unable to locate a domain controller, which usually indicates DNS problems.	Troubleshoot failure to locate domain controller when attempting to join a domain.

Troubleshooting Active Directory Replication Failure Due to Incorrect DNS Configuration

Improper DNS configuration can lead to a wide variety of failures, because all Active Directory services depend on the ability of the devices to locate domain controllers, which is performed through DNS queries.

Procedures for Troubleshooting Active Directory Replication Failure Due to Incorrect DNS Configuration

1. Verify DNS records and determine whether all the necessary DNS records of the source domain controller exist in the DNS server used by the destination domain controller.

2. If the destination domain controller is able to resolve the necessary DNS records, the problem is most likely with network connectivity or a stopped or malfunctioning Active Directory-related service. Use the Ping command to verify network connectivity between the source domain controller and the destination domain controller.

If the Ping command fails, you must troubleshoot network connectivity between the source domain controller and the destination domain controller. For more information about troubleshooting network connectivity, see “TCP/IP Troubleshooting” in the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit.

If you are able to ping the destination domain controller, troubleshoot Active Directory–related services. Verify that they are started and functional. For more information about troubleshooting Active Directory–related services, see “Verifying Service Health” in this guide, or see the individual sections in this guide for each service.

If you are unable to resolve the problem, contact either your designated support provider or Microsoft Product Support Services.

3. If the destination domain controller is not able to resolve the necessary DNS records, then the problem is most likely with DNS configuration.

a. Verify network configuration to ensure that the preferred and alternate DNS server settings specified in the IP configuration of the destination domain controller are correct. For more information about correct DNS server settings for Active Directory, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresources. Search under “Planning & Deployment Guides” and download Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks.

b. If the settings for the destination domain controller are incorrect, change the configuration, flush the DNS cache, and retry the operation that failed.

– or –

If the client settings for the destination domain controller are configured correctly, verify that the primary zone that is authoritative for the CNAME resource record for <DSAGuid>._msdcs.<ForestName> allows dynamic updates. (DSAGuid is a value of the objectDSA attribute of the NTDS Settings container for the Server object corresponding to the source domain controller.)

At a command prompt on the source domain controller, type the following command and press ENTER:

dcdiag /test:registerindns /dnsdomain

If the primary zone that is authoritative for the CNAME resource record does not allow dynamic updates, enable secure dynamic updates on this zone.

Repeat this step for the A resource record of the source domain controller.

c. Verify network configuration to ensure that the preferred and alternate DNS server settings specified in the IP configuration of the source domain controller are correct. For more information about correct DNS server settings for Active Directory, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresourcesSearch under “Planning & Deployment Guides” and download Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks.

d. If the settings for the source domain controller are incorrect, change the configuration, flush the DNS cache, and stop and start the Net Logon service.

e. Verify that the required DNS resource records are registered on the destination domain controller. At a command prompt, type the following command and press ENTER:

dcdiag /test:connectivity

f. Flush the DNS cache and retry replication.

4. If the problem continues, it might be due to a problem with DNS data replication. Review your DNS design to determine whether it includes end-to-end DNS replication. Determine whether DNS replication is failing due to an Active Directory replication failure. For more information about detecting and troubleshooting an Active Directory replication failure, see “Troubleshooting Active Directory Replication” in this guide.

5. If the problem continues, configure the IP settings of the affected domain controllers so that they all have the same primary and secondary DNS servers. Then stop and start Net Logon, flush the DNS cache, and retry the operation that failed. This is a temporary configuration that you can use to recover from the failure, but be sure to return to the original configuration that you designed based on the recommendations provided in Best Practice Active Directory Design for Managing Windows Networks. For more information about correct DNS server settings for Active Directory, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresourcesSearch under “Planning & Deployment Guides” and download Best Practice Active Directory Deployment for Managing Windows Networks.

6. If the problem continues, see more DNS troubleshooting information in “Windows 2000 DNS” in the TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit.

Troubleshooting Domain Controller Locator DNS Records Registration Failure

Presence of the event IDs 5774, 5775, or 5781 logged by the Net Logon service in the System Event Log indicate that the corresponding domain controller cannot dynamically register DNS records that advertise its availability as a domain controller. The consequence of this failure is that domain controllers, domain members, and other devices cannot locate this domain controller. As a result, other domain controllers might not be able to replicate from this domain controller. In addition, other computers might not be able to join this domain, and you might not be able to add other domain controllers to this domain (unless other domain controllers for this domain have successfully registered domain controller Locator DNS records).

Procedures for Troubleshooting Domain Controller Locator DNS Records Registration Failure

1. Verify network configuration to ensure that the preferred and alternate DNS servers specified in the IP configuration of the domain controller are correct. For more information about correct DNS settings, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkID=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresourcesSearch under “Planning & Deployment Guides” and download Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks. If the problem persists, continue to the next step.

2. At a command prompt, type the following command and press ENTER:

dcdiag /test:registerindns /dnsdomain:FQDN /v

3. Follow the recommendations provided in the output.

Troubleshooting Active Directory Installation Wizard Failure to Locate Domain Controller

To install Active Directory on a server in an existing Active Directory forest, the server must be able to locate a domain controller for the same domain (if you are adding a domain controller to an existing domain) or for the forest root domain.

Procedures for Troubleshooting Active Directory Installation Wizard Failure to Locate Domain Controller

1. Verify network configuration to ensure that the preferred and alternate DNS servers specified in the IP configuration of the server that is being promoted are correct. For more information about correct DNS settings, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresourcesSearch under “Planning & Deployment Guides” and download Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks. If the problem persists, continue to the next step.

2. At a command prompt, type one of the following commands and press ENTER:

dcdiag /test:dcpromo /dnsdomain:FQDN /NewTree /ForestRoot:Forest_Root_Domain_DNS_Name/v

dcdiag /test:dcpromo /dnsdomain:FQDN /ChildDomain /v

dcdiag /test:dcpromo /dnsdomain:FQDN /ReplicaDC /v

This tests the existing DNS infrastructure to see whether a domain controller can be promoted.

3. Follow the recommendations provided in the output.

Troubleshooting Failure to Locate Domain Controller when Attempting to Join a Domain

Failure to join a computer to an existing Active Directory domain because the computer cannot locate a domain controller for the domain is usually caused by incorrect DNS configuration.

Procedures for Troubleshooting Failure to Locate Domain Controller when Attempting to Join a Domain

1. Verify network configuration to ensure that the preferred and alternate DNS servers specified in the IP configuration of the computer attempting to join the domain are correct. For more information about correct DNS settings, see the Active Directory link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresources. Search under “Planning & Deployment Guides” and download Best Practice Active Directory Design for Managing Windows Networks and Best Practice Active Directory Deployment for Managing Windows Networks. If there is still a problem, continue to the next step.

2. At a command prompt, type the following and press ENTER:

netdiag /test:dsgetdc /d:DomainName /v

3. If any of the tests fail, follow the recommendations provided in the output.

Troubleshooting FRS

FRS supports a multimaster file replication model in which any computer can originate or accept changes to any other computer taking part in the replication configuration. Before you troubleshoot FRS problems, understand the following characteristics of multimaster file replication:

· Be aware of how changes made in replicated file areas, including the bulk reset of permissions or other file attributes by administrators or applications, can affect bandwidth.

· Any changes to the file system will eventually occur on all other members of the replication set. Do not try to speed up the process by making the same change on other FRS replication partners. This could result in data errors.

· If, after modifying a file, you notice that it has somehow reverted back to a previous version, another operator or application might be making changes in the same area, overwriting the earlier changes. In this case, try to find the other operator or application that is causing the problem.

· Any files that you delete on one member will be deleted on all other members.

· If you rename a file or folder so that it is moved out of the replication tree, FRS will treat it as a deletion on the other replication set members because the file or folder has disappeared from the scope of the replica set.

· If two operators create a file or folder at the same time (or before the change has replicated), the file or folder will “morph,” or receive a modified name, such as folder_ntfrs_012345678. FRS behaves this way in order to avoid data loss in such situations.

· Keep the FRS service running at all times in order to avoid a journal wrap condition.

Table 2.6 shows common events and symptoms that indicate FRS problems and the solution or action required.

Table 2.6   Events and Symptoms that Indicate FRS Problems

Event or Symptom	Root Cause	Solution
FRS Event ID 13508	FRS was unable to create an RPC connection to a replication partner.	If this message is not followed by an FRS event ID 13509, troubleshoot FRS event ID 13508 without FRS event ID 13509.
FRS Event ID 13509	FRS was able to create an RPC connection to a replication partner.	No action required.
FRS Event ID 13511	The FRS database is out of disk space.	Treat this as a priority 1 problem. Troubleshoot FRS event ID 13511.
FRS Event ID 13522	The staging area is full.	If you are using Windows 2000 SP2 or earlier, treat this as a priority 1 problem. If you are using SP3, treat this as a priority 3 problem. Troubleshoot FRS event ID 13522.
FRS Event ID 13526	The SID cannot be determined from the distinguished name.	Treat this as a priority 1 problem. Troubleshoot FRS event ID 13526.
FRS Event ID 13548	System clocks are too far apart on replica members.	Treat this as a priority 1 problem. Troubleshoot FRS event ID 13548.
FRS Event ID 13557	Duplicate connections are configured.	Treat this as a priority 1 problem. Troubleshoot FRS event ID 13557.
FRS Event ID 13567	Excessive replication was detected and suppressed.	Treat this as a priority 2 problem. Troubleshoot FRS event ID 13567.
FRS Event ID 13568	Journal wrap error.	If you are using Windows 2000 SP2 or earlier, treat this as a priority 2 problem. If you are using SP3, treat this as a priority 1 problem. Troubleshoot FRS event ID 13568.
Files are not replicating	Files can fail to replicate for a wide range of underlying reasons: DNS, file and folder filters, communication issues, topology problems, insufficient disk space, FRS servers in an error state, or sharing violations.	Troubleshoot files not replicating.
Modified folder names on other domain controllers	If duplicate folders are manually created on multiple domain controllers before they have been able to replicate, FRS preserves content by ”morphing” folder names of the last folders to be created.	Troubleshoot morphed folders.
SYSVOL data appears on domain controllers, but \\<domain>\SYSVOL share appears to be empty	SYSVOL folders include a reparse point that points to the correct location of the data. You must take special steps to recover a deleted reparse point.	Troubleshoot the SYSVOL directory junction.
Excessive disk or CPU usage by FRS	A service or application is unnecessarily changing all or most of the files in a replica set on a regular basis. For example, an antivirus software package might be rewriting the ACL on many files, causing FRS to replicate these files unnecessarily.	Troubleshoot excessive disk and CPU usage by NTFRS.exe.

General Procedures for Troubleshooting FRS Problems

For troubleshooting FRS, you can use the Ntfrsutl.exe tool in the Windows 2000 Resource Kit. With Ntfrsutl, you can do the following:

· Show the FRS configuration in Active Directory.

· List the active replica sets in a domain.

· Show the ID table, inbound log, or outbound log for a computer hosting FRS.

· Examine memory usage by FRS.

· List the application programming interface (API) and version number for FRS.

· Poll immediately, quickly, or slowly for changes to the FRS configuration.

Ntfrsutl can be used on remote computers, so you can get status information of any member of a replica set from single console.

For more information about troubleshooting FRS, see the File Replication Service (FRS) link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresources.

Troubleshooting FRS Events 13508 without FRS Event 13509

FRS event ID 13508 is a warning that the FRS service has been unable to complete the RPC connection to a specific replication partner. It indicates that FRS is having trouble enabling replication with that partner and will keep trying to establish the connection.

A single FRS event ID 13508 does not mean anything is broken or not working, as long as it is followed by FRS event ID 13509, which indicates that the problem was resolved. Based on the time between FRS event IDs 13508 and 13509, you can determine if a real problem needs to be addressed.

Note

If FRS is stopped after an event ID 13508 is logged and then later started at a time when the communication issue has been resolved, event ID 13509 will not appear in the event log. In this case, look for an event indicating that FRS has started, and ensure it is not followed by another event 13508.

Because FRS servers gather replication topology information from the closest domain controller, a replica partner in another site will not be aware of the replica set until the topology information has been replicated to domain controllers in that site. When the topology information finally reaches that distant domain controller, the FRS partner in that site will be able to participate in the replica set and FRS event ID 13509 will be logged. Intrasite Active Directory replication partners replicate every five minutes. Intersite replication only replicates when the schedule is open (the shortest delay is 15 minutes). In addition, FRS polls the topology at defined intervals: five minutes on domain controllers, and one hour on other member servers of a replica set. These delays and schedules can delay propagation of the FRS replication topology, especially in topologies with multiple hops.

Procedures for Troubleshooting FRS Event 13508 without Event 13509

1. Examine the FRS event ID 13508 to determine the machine that FRS has been unable to communicate with.

2. Determine whether the remote machine is working properly, and verify that FRS is running on it. Type the following command at a command prompt on the computer that logged the FRS event ID 13508 and press ENTER:

ntfrsutl version <FQDN of remote domain controller>

If this fails, check network connectivity by using the Ping command to ping the fully qualified domain name (FQDN) of the remote domain controller from the computer that logged the FRS event ID 13508. If this fails, then troubleshoot as a DNS or TCP/IP issue. If it succeeds, confirm that the FRS service is started on the remote domain controller.

3. Determine whether FRS has ever been able to communicate with the remote computer by looking for FRS event ID 13509 in the event log and see if the FRS problem correlates to recent change management to networking, firewalls, DNS configuration, or Active Directory infrastructure.

4. Determine whether anything between the two machines is capable of blocking RPC traffic, such as a firewall or router.

5. Confirm that Active Directory replication is working. For more information about troubleshooting Active Directory replication, see “Troubleshooting Active Directory Replication Problems” in this guide.

Troubleshooting FRS Event 13511

FRS event ID 13511 is logged when the FRS database is out of disk space. To correct this situation, delete unnecessary files on the volume containing the FRS database. If this is not possible, then consider moving the database to a larger volume with more free space. For more information about how to move the database to a larger volume, see Knowledge Base article Q221093: How to Relocate the NTFRS Jet Database and Log Files. To view this Knowledge Base article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

Troubleshooting FRS Event 13522

The Staging Directory is an area where modified files are stored temporarily either before being propagated to other replication partners or after being received from other replication partners. FRS encapsulates the data and attributes associated with a replicated file or directory object in a staging file. FRS needs adequate disk space for the staging area on both upstream and downstream machines in order to replicate files.

On Windows 2000 SP2 and earlier, FRS event 13522 indicates that the FRS service has paused because the staging area is full. Replication will resume if disk space for the staging area becomes available or if the disk space limit for the staging area is increased.

On Windows 2000 SP3, you must clear the replication backlog. Reasons why the staging area might fill up include:

· One or more downstream partners are not accepting changes. This could be a temporary condition due to the schedule being turned off and FRS waiting for it to open, or a permanent state because the service is turned off, or the downstream partner is in an error state.

· The rate of change in files exceeds the rate at which FRS can process them.

· No obvious changes are made to the files but the staging area is filling up anyway. To troubleshoot this excessive replication, see “Troubleshooting FRS Event 13567” in this guide.

· A parent directory for files that have a large number of changes is failing to replicate in so all changes to subdirectories are blocked.

Troubleshooting FRS Event 13526

FRS event ID 13526 is logged when a domain controller becomes unreachable. This problem occurs because FRS polls Active Directory at regular intervals to read FRS configuration information. During the polling, an operation is performed to resolve the security identifier (SID) of an FRS replication partner. The binding handle might become invalid if the bound domain controller becomes unreachable over the network or restarts in a single polling interval (the default is five minutes).

To resolve this issue, stop and start FRS on the computer logging the error message.

Troubleshooting FRS Event 13548

FRS event ID 13548 is logged when the time settings for two replication partners differ by more than 30 minutes. This error could be caused by the selection of an incorrect time zone on the local computer or its replication partner.

Check that the time zone and system clock are correctly set on both computers. They must be within 30 minutes of each other, but preferably much closer.

Troubleshooting FRS Event 13557

FRS event ID 13557 is logged when duplicate connections are detected between two replication partners. To resolve this problem, delete duplicate connection objects between the direct replication partners that are noted in the event text.

Troubleshooting FRS Event 13567

Event 13567 in the FRS event log is generated on computers running Windows 2000 SP3 when unnecessary file change activity is detected.

Unnecessary file change activity means that a file has been written by some user or application, but no change is actually made to the file. FRS detects that the file has not changed, and maintains a count of how often this happens. If the condition is detected more than 15 times per hour during a three-hour period, FRS logs the 13567 event.

Determine the application or user that is modifying file content. For procedures to troubleshoot this issue, see “Troubleshooting Excessive Disk and CPU Usage by NTFRS.EXE” in this guide. More information can also be found in Knowledge Base article Q315045: FRS Event 13567 Is Recorded in the FRS Event Log with SP3. To view this Knowledge Base article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

Troubleshooting FRS Event 13568

FRS event ID 13568 contains the following message:

The File Replication Service has detected that the replica set "1" is in JRNL_WRAP_ERROR.

NTFS maintains a special log called the NTFS USN journal, which is a high-level description of all the changes to files and directories on an NTFS volume. FRS uses this mechanism in order to track changes to NTFS directories of interest, and to queue those changes for replication to other computers. The NTFS USN journal has defined size limits and will discard old log information on a first-in, first-out basis in order to maintain its correct size.

If FRS processing falls behind the NTFS USN journal, and if NTFS USN journal information that FRS needed has been discarded, then FRS enters a journal wrap condition. FRS then needs to rebuild its current replication state with respect to NTFS and other replication partners.

Each file change on the NTFS volume occupies approximately 100 bytes in this journal (possibly more, depending on the file name size). In general, the NTFS USN journal for an NTFS volume should be sized at 128 megabytes (MB) per 100,000 files being managed by FRS on that NTFS volume.

In Windows 2000 SP2 and earlier, the default journal size is 32 MB and the maximum journal size is 128 MB. In Windows 2000 SP3, the default journal size is 128 MB, and the maximum journal size is 10,000 MB

The journal size can be configured with a registry subkey, but keep in mind that once you increase journal size you should not lower it again because this will cause a journal wrap. To learn how the USN journal size can be increased see Knowledge Base article Q221111: Description of FRS Entries in the Registry. To view this Knowledge Base article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

FRS can encounter journal wrap conditions in the following cases:

· Many files are added at once to a replica tree while FRS is busy, starting up, or not running.

· On a server that is being used for authoritative restore, or as the primary server for a new replica partner, excessive file activity at the start of this process can consume NTFS USN journal records. Size the NTFS volume at 128 MB per 100,000 files being managed by FRS, as mentioned above, to avoid this condition.

· NTFS needs to be processed with Chkdsk and Chkdsk corrects the NTFS structure. In this case, NTFS creates a new NTFS USN journal for the volume or deletes the corrupt entries from the end of the journal.

· The NTFS USN journal is deleted or reduced in size.

· FRS is in an error state that prevents it from processing changes in the NTFS USN journal.

If FRS is experiencing journal wrap errors on a particular server, it cannot replicate files until the condition has been cleared. To continue replication, the administrator must stop FRS on that server and perform a non-authoritative restore of the data so that the system can synchronize with its replication partners. For more information about performing a non-authoritative restore, see “Performing a Non-Authoritative Restore” in this guide.

Note the following:

· Windows 2000 SP1 cannot perform this process automatically.

· In Windows 2000 SP2, FRS performs this process automatically.

· In Windows 2000 SP3, FRS does not perform this process automatically. The reason for this change was that it was typically being performed at times that were not planned by administrators. However, a registry setting is available that allows FRS to perform the automatic nonauthoritative restore, just as in Windows 2000 SP2. However, it is recommended to leave this as a manual process.

For more information about performing the nonauthoritative restore process on a server, see Knowledge Base article Q292438: Troubleshooting Journal Wrap Errors on SYSVOL and DFS Replica Sets. To view this Knowledge Base article, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources.

Troubleshooting Files Not Replicating

Files can fail to replicate for a wide range of causes. As a best practice, find the root cause of FRS replication problems.

Procedures for Troubleshooting Files that Are Not Replicating

1. Verify that Active Directory replication is functioning. For more information about troubleshooting Active Directory replication, see “Troubleshooting Active Directory Replication Problems” in this guide. Each domain controller must have at least one inbound connection to another domain controller in the same domain.

2. Examine the event logs on the machines involved. Resolve any problems found.

3. Use the Ntfrsutl ver command from the source to the destination computer, and vice versa. Verify that the addresses are correct. Verify RPC connectivity between the source and destination. Also verify that FRS is running.

4. Use the Services administrative console to confirm that FRS is running on the remote computer.

5. If FRS is not running, review the File Replication service event log on the problem computer. If the service has asserted, troubleshoot the assertion. Otherwise, restart the service by using the net start ntfrs command.

6. Verify that Active Directory replication is functioning. If it is not, see “Troubleshooting Active Directory Replication Problems” in this guide.

7. Use Active Directory Sites and Services to verify the replication schedule on the connection object to confirm that replication is enabled between the source and destination computers and also that the connection is enabled. The connection object is the inbound connection from the destination computer under the source computer’s NTFRS_MEMBER object. For SYSVOL, the connection object resides under \Servers\server_name\NTDS Settings.

8. Create a test file on the destination computer, and verify its replication to the source computer, taking into account the schedule and link speed for all hops between the two computers.

9. Check for files that are larger than the amount of free space on the source or destination server or larger than the size of the staging area directory limit in the registry. Resolve the disk space problem or increase the maximum staging area file space. For more information about troubleshooting staging area problems, see “Troubleshooting FRS Event 13522” in this guide.

10. Check whether the source file was excluded from replication. Confirm that the file is not encrypted by using Encrypting File System (EFS), an NTFS junction point (as created by Linkd.exe from the Windows 2000 Server Resource Kit), or excluded by a file or folder filter on the originating replica member. If any of these conditions are true, FRS does not replicate such files or directories.

11. Check whether the file is locked on either computer. Use the net file command on the source and destination computers. This command indicates which users are holding the file open on the network, but will not report any files being held open by local processes.

· If the file is locked on the source computer, then FRS will be unable to read the file to generate the staging file, and replication will be delayed. If the file is locked on the destination computer, then FRS will be unable to update the file. In this case, FRS continues to retry the update until it succeeds. The retry interval is 30 to 60 seconds.

· If files are being held open by remote users, you can use the net file <id> /close command to force the file closed.

If these methods do not resolve the issue, you can investigate the FRS debug logs to get more details on what is causing the replication to fail. FRS creates text-based logs in the %systemroot%\debug\ntfrs_*.log directory to help you debug problems. Debug logs effectively describe a two-way conversation between replication partners. A higher value indicates the log is more recent (for example, ntfrs_0001.log is oldest and ntfrs_0005.log is newest).

To observe a particular event, take a snapshot of the log files as close to the occurrence of the event as possible. Save the log files in a different directory so they can be examined afterward. Debug lines containing the string :T: are known as “tracking records” and are typically the most useful for understanding why specific files fail to replicate. You can redirect records of interest to a text file using the FINDSTR command. For example:

findstr /I ":T:" %systemroot%\debug\ntfrs_*.log >trackingrecords.txt

findstr /I "error warn fail S0" %systemroot%\debug\ntfrs_*.log >errorscan.txt

Important

SYSVOL uses FRS as the means to replicate data. When troubleshooting FRS, focus on how to enable it to run again, instead of trying to “help” replication by manually copying files to replication partners. This can be used as a stop gap, but requires reinitializing the entire replica set. Manually copying files can cause additional replication traffic, backlogs, and potential replication conflicts. For more information about replication conflicts, see “Troubleshooting Morphed Folders” later in this guide.

Verifying the FRS Topology in Active Directory

Because FRS servers gather their replication topology information from their closest Active Directory domain controller, FRS replication relies on Active Directory replication functioning properly. Two approaches to verifying that Active Directory is replicating FRS replication topology information correctly include:

u Verify Active Directory replication is functioning.

u Verify the FRS topology in Active Directory from multiple servers.

For more information about verifying the FRS topology, see the File Replication Service (FRS) link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page </A>at http://www.microsoft.com/windows/reskits/webresources.

Troubleshooting Morphed Folders

All files and folders that FRS manages are uniquely identified internally by a special file identifier. FRS uses these identifiers as the canonical identifiers of files and folders that are being replicated. If FRS receives a change order to create a folder that already exists, which by definition has a different file identifier than the duplicate folder, FRS protects the conflicting change by leaving the original directory structure intact, and renaming the conflicting directory to a unique name so that underlying files and folders can be preserved.

The conflicting folder will be given a new name of the form FolderName_NTFRS_<guidname> where FolderName was the original name of the folder and GUID is a unique character string like “001a84b2.”

Two common causes of this condition are:

· A folder is created on multiple machines in the replica set before the folder has been able to replicate. This could be due to the administrator or application duplicating folders of the same name on multiple FRS members.

· You initiate an authoritative restore on one server and either:

· Did not stop the service on all other members of the reinitialized replica set before restarting FRS after the authoritative restore, or

· Did not set the D2 registry key for the authoritative restore on all other members of the reinitialized replica set before a server replicated outbound changes to reinitialized members of the replica set.

· Manually copied directories with names identical to those being replicated by FRS to computers in the replica set.

For more information about performing an authoritative restore, see “Active Directory Backup and Restore” in this guide.

To recover from morphed folders you have two options:

· Move the morphed directories out of the replica tree and back in

_OR_

· Rename the morphed directories.

The first method works well for small amounts of data on a small number of targets. However, if you miss end-to-end replication of the move-out, this method can cause morphed directories. This method also forces all members to re-replicate data. The second method does not require re-replication of data. However, it can cause a denial-of-service condition by giving an invalid path when the originating path is renamed.

Procedures for Moving Morphed Directories Out of the Replica Tree and Back In

1. Move all morphed directories out of the tree.

2. Wait for end-to-end removal of data on all targets.

3. While waiting, build a tree containing the desired files and folder versions, including permissions and other attributes.

4. Verify end-to-end deletion of the “move-out” on all targets, otherwise you get a conflict in the next step. Perform a nonauthoritative restore of computers that did not replicate in the deletion. Disable FRS on computers that you could not restore. For more information about authoritative and nonauthoritative restores, see “Active Directory Backup and Restore” in this guide.

5. Move data from outside of tree to inside of the replicated tree. Use the SCOPY or XCopy /O command to preserve permissions.

Procedures for Renaming Morphed Directories

1. From the computer that originated the good series in conflict, rename both the good and morphed variants to a unique name.

2. Verify end-to-end replication of the rename operation across all members of the set. For those that do not get the rename within the necessary point in time, stop FRS and set the D2 registry setting for a nonauthoritative restore. Do not restart the computer at this time.

3. Move any files from the now renamed morphed folders to the renamed good folders.

4. Verify end-to-end replication of the files in the renamed original folder.

5. Delete the original morphed files.

6. Restart FRS to start the authoritative restore. After the rename has propagated, it can be deleted. Before deleting any of the folders, ensure that you have a backup of the original (and complete) folder.

Troubleshooting the SYSVOL Directory Junction

The SYSVOL share contains two folders that are directory junctions that point to other folders, much like a symbolic link.

Procedures for Troubleshooting the SYSVOL Directory Junction

1. At a command prompt, type the following commands and press ENTER:

dir <drive>:\<path>\SYSVOL\SYSVOL

dir <drive>:\<path>\SYSVOL\Staging Areas

Verify that junction points are in place. The following output example shows junction points.

D:\WINNT\SYSVOL\sysvol>dir

06/26/2001 01:23p <DIR> .

06/26/2001 01:23p <DIR> ..

06/26/2001 01:23p <JUNCTION> corp.com

D:\WINNT\SYSVOL\staging areas>dir

06/26/2001 01:23p <DIR> .

06/26/2001 01:23p <DIR> ..

06/26/2001 01:23p <JUNCTION> corp.com

2. If either of the two junction points is missing, use the Linkd.exe tool from the Windows 2000 Server Resource Kit to recreate them. At a command prompt, type the following command and press ENTER:

linkd <drive>:\<path>\SYSVOL\SYSVOL\<fully qualified domain name> <drive>\<path>\SYSVOL\<domain>

linkd <drive>:\<path>\SYSVOL\Staging Areas\<fully qualified domain name> <drive>\<path>\SYSVOL\<domain>

Verify the same path for staging and staging areas.

Caution

Take great care when copying folders that include directory junctions. When Xcopy copies such a tree in Windows 2000, it copies the junction, not the contents of the folder the junction points to. An administrator can accidentally delete SYSVOL by using the RD /S command on a copy made of SYSVOL. Use RD without the /S parameter instead, because RD /S will follow the directory junction, but the RD command without /S will not.

Troubleshooting Excessive Disk and CPU Usage by NTFRS.EXE

Extensive replication generators are applications or operations that change all or most of the files in a replica set on a regular basis without the changes being necessary. FRS monitors the USN journal for changes, and if it finds a change, it has to replicate this file. The applications that create extensive replication normally rewrite the ACL (in the case of file security policies and antivirus software) or rewrite the file (in the case of defragmentation software). In both cases, the content, permissions, and attributes on the file or directory are not really changed.

For Windows 2000 SP 3, Event ID 13567 in the FRS event log records that this kind of “non change” was suppressed in order to prevent unnecessary replication. In versions of Windows 2000 earlier than SP3, extensive replication generators were the most common reason for staging areas to fill up. Administrators should still look for and eliminate extensive replication generators when using SP3, because the file comparison consumes disk and file resources.

You can use one of the following methods to identify excessive replication generators:

· Selectively turn off common causes such as antivirus software, defragmentation tools, and file system policy, and determine if this activity declines.

· Use the FileSpy tool from the Windows 2000 Server Resource Kit to identify file information.

· Inspect the NTFRSUTL OUTLOG report to see which files are being replicated.

· Inspect the USN journal tracking records in the FRS debug logs on computers running Windows SP2 or later with the following command:

Findstr /I ":U:" %systemroot%\debug\ntfrs_00*.log

For more information about troubleshooting excessive disk and CPU usage by Ntfrs.exe, see the following Knowledge Base articles:

· Q284947: “Norton AntiVirus 7.x Makes Changes to Security Descriptors”

· Q282791: “FRS: Disk Defragmentation Causes FRS Replication Traffic”

· Q279156: “Effects of Setting File System Policy on a Disk Drive or Folder”

· Q307777: “Possible Causes of a Full File Replication Service Staging Area”

To view these Knowledge Base articles, see the Microsoft Knowledge Base link on the <A HREF="http://go.microsoft.com/fwlink/?LinkId=291" TARGET="_blank">Web Resources page</A> at http://www.microsoft.com/windows/reskits/webresources. For more information about troubleshooting high CPU usage on a domain controller, see “Troubleshooting High CPU Usage on a Domain Controller” in this guide.

Troubleshooting Active Directory Replication Problems

Active Directory replication problems can have several different sources. For example, DNS problems or incorrect site configuration can cause Active Directory replication to fail. Table 2.7 shows common events that might indicate a problem with Active Directory replication, together with root cause and solution information.

Table 2.7   Events that Indicate Active Directory Replication Problems

Event	Root Cause	Solution
Net Logon Event ID 5805	A machine account failed to authenticate, which is usually caused by either multiple instances of the same computer name, or the computer name has not replicated to every domain controller.	If you do not find multiple instances of the computer name, verify that replication is functioning for the domain that contains the computer account.
NTDS Event ID 1083	A duplicate object is present in the Active Directory of the replication partner of the local domain controller, so updating it is impossible.	See “Troubleshooting Directory Data Problems” in this guide.
NTDS Event ID 1265	Replication failed for the reason stated in the message text.	Use Repadmin.exe to further identify the problem, and use Table x.x to determine the appropriate action to take for the message generated by Repadmin.exe. If the event message indicates a DNS lookup failure or the RPC server is unavailable, see “Troubleshooting Active Directory–Related DNS Problems” in this guide. If the event message indicates that the target account name is incorrect, troubleshoot GUID discrepancies. If the event message indicates a time difference between the client and server, synchronize replication from the PDC emulator.
NTDS Event ID 1311	This error occurs when the replication configuration information in Active Directory Sites and Services does not accurately reflect the physical topology of the network.	Troubleshoot NTDS event ID 1311.
NTDS Event ID 1388	This error is usually generated by a lingering object which resulted from disconnecting a domain controller for too long.	If the domain controller does not also function as a global catalog server, see “Remove Lingering Objects from an Outdated Writable Domain Controller.” If the domain controller also functions as a global catalog server, see “Remove Lingering Objects from a Global Catalog Server.”
NTDS Event ID 1645	This error occurs over an existing replication link when the GUID of the NTDS Settings object of a replication partner does not match the GUID defined in the Service Principal Name (SPN) attributes of the computer object of this replication partner.	Troubleshoot GUID discrepancies.
SceCli event ID 1202	A user account in one or more Group Policy objects (GPOs) cannot be resolved to a security identifier (SID). This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights Assignment or Restricted Groups branch of a GPO.	Troubleshoot SceCli event ID 1202.

General Guidelines for Troubleshooting Replication Problems

To identify Active Directory replication problems, use the repadmin /showreps command. Table 2.8 shows the error message generated by this command, together with root cause and solution information.

Table 2.8   Repadmin /Showreps Error Messages

Repadmin Error	Root Cause	Solution
No inbound neighbors.	If no items appear in the “Inbound Neighbors” section of the output generated by the repadmin /showreps command, the domain controller was not able to establish replication links with another domain controller.	See “Troubleshoot No Inbound Neighbors Repadmin.exe Error.”
Access is denied.	A replication link exists between two domain controllers, but replication cannot be properly performed.	See “Troubleshoot Access Denied Replication Errors.”
Last attempt at <date - time> failed with the “Target account name is incorrect.”	This problem can be related to connectivity, DNS, or authentication issues. If it is a DNS error, the local domain controller could not resolve the GUID–based DNS name of its replication partner.	See “Troubleshooting Active Directory-Related DNS Problems.” Also see “Troubleshoot Access Denied Replication Errors.”
No more end point.	This can be caused because no more end-points are available to establish the TCP session with the replication partner. This error can also result when the replication partner can be contacted, but its RPC interface is not registered. This usually indicates that the domain controller’s DNS name is registered but with the wrong IP address.	Use Netstat to check the currently established sessions. Free up TCP sessions, if necessary. Correct the IP address and see “Troubleshooting Active Directory–related DNS Problems.”
LDAP Error 49.	The domain controller computer account might not be synchronized with the Key Distribution Center (KDC).	See “Troubleshoot Access Denied Replication Errors.”
Cannot open LDAP connection to local host.	The administration tool could not contact Active Directory.	See “Troubleshooting Active Directory-Related DNS Problems.”
AD replication has been preempted.	An inbound replication in progress was interrupted by a higher priority replication request, such as a request generated manually by using the repadmin /sync command.	Wait for replication to complete.
Replication posted, waiting.	The domain controller posted a replication request and is waiting for an answer. Replication is in progress from this source.	Wait for replication to complete.
Last attempt @never was successful.	· The KCC successfully created the replication link between the local domain controller and its replication partner, but because of the schedule or possible bridgehead overload, replication has not occurred. · A large backlog of inbound replication must be performed on this domain controller.	· Synchronize replication from a source domain controller. Use the repadmin /queue <domain controller> command to check how many inbound synchronizations are in the queue.

For more information about replication concepts, see “Active Directory Replication” in the Distributed Systems Guide of the Windows 2000 Server Resource Kit.

Troubleshooting No Inbound Neighbors Repadmin.exe Error

When no items appear in the “inbound neighbors” section of the repadmin /showreps command output, one of the following conditions exists:

· No connection object exists to indicate which domain controller(s) this domain controller should replicate from. These connection objects are typically created by the KCC. However, in some environments, administrators have turned off the part of the KCC that creates connection objects for inbound replication from domain controllers in other sites, relying on manual connections instead.

· One or more connection objects exist, but the domain controller is unable to contact the source domain controller to create the replication links. In this case, the KCC logs events each time it runs (by default, every 15 minutes) detailing the error that occurred when it attempted to add the replication links.

Ensure that a connection object has been properly created between the domain controller and its replication partner. If not, then create the connection object.

Procedures for Troubleshooting No Inbound Neighbors

1. Verify connection object.

2. If no connection object exists, create a connection object.

3. After you create the connection objects, see “Linking Sites for Replication” for procedures to create a site link. Replication should occur automatically at the scheduled time.

Troubleshooting Access Denied Replication Errors

This error indicates that the local domain controller failed to authenticate against its replication partner when creating the replication link or when trying to replicate over an existing link. This typically happens when the domain controller has been disconnected from the rest of the network for a long time and its computer account password is not synchronized with the computer account password that is stored in the Active Directory of its replication partner.

Procedures for Troubleshooting Access Denied Replication Errors

1. Confirm naming context permissions on direct replication partners by using the dcdiag /test:ntsec command. Verify replication is functioning. If replication is not functioning properly, continue with the next step.

2. Confirm that the Enterprise Domain Controllers group contains the “access this computer from network” right. If you have to add this right, ensure the domain has applied group policy before proceeding. Verify replication is functioning. If replication is not functioning properly, continue with the next step.

3. Stop the KDC on the local domain controller.

4. Purge the ticket cache on the local domain controller.

5. Verify that the domain controller is in the Domain Controllers OU, the default domain controllers GPO is linked to the OU, and the “access this computer from network” policy is effective in this domain.

6. Reset the computer account password on the PDC emulator.

7. Synchronize the domain naming context of the replication partner with the PDC emulator.

8. If the repadmin /showreps command shows no replication partner, see “Link Sites for Replication” in this guide for procedures to create a replication link.

9. Synchronize replication from a source domain controller.

10. Start the KDC on the local domain controller.

11. If you get a new “access denied” error message, you must create a temporary connection link between the domain controller and its replication partner for the naming contexts.

Troubleshooting GUID Discrepancies

When a domain controller creates a replication link with its replication partner, it looks in its Active Directory for the GUID of the NTDS Settings object of its replication partner. It then checks whether the GUID matches the replication SPN present in the ServicePrincipalName of the computer object of its replication partner. If they don’t match, the replication link cannot be established, and it logs an event in the Directory Services event log.

This can happen when a domain controller has been manually removed from the Active Directory and then Active Directory is reinstalled on the domain controller. After Active Directory is reinstalled, the domain controller gets a new GUID for its NTDS Settings object and creates a new replication SPN accordingly.

Procedures for Troubleshooting GUID Discrepancies

1. Identify the GUID of the replication partner. If several entries are returned, this is the source of the error. One of entries results from the initial installation of Active Directory on the replication partner. If Active Directory was removed from the domain controller without running the Active Directory Installation Wizard, and then Active Directory was reinstalled on the domain controller, a new NTDS Settings object was created (with a new GUID) and was replicated to this domain controller. In that case, determine which NTDS Settings object has the correct GUID and delete the incorrect NTDS Settings object.

2. Verify that a DNS record for the bad NTDS Settings object has not been created on the root DNS server. Verify DNS records for <replication_partner_guid>._msdcs.<forest_root_domain_name>. Verify that only one DNS record for <replication_partner>.<regional_domain_name> is present with the right GUID. If several records are present, delete the incorrect records.

3. If the previous step revealed only one NTDS Settings object with the correct GUID, verify the SPN for the replication partner on the local domain controller. If the name does not exist or contains a GUID which does not match its replication partner, it must be created in the Active Directory of the local domain controller. If the name exists with a different GUID, it must be modified to match the correct GUID.

To do this, run ADSI Edit or LDP on the local domain controller. Locate the SPN in the multivalued attribute ServicePrincipalName of the computer object of the replication partner (CN=<computer_name>,OU=Domain Controllers,DC=dom1,DC=company,DC=com) and change the replication SPN to the correct value.

4. Verify that replication is functioning.

Troubleshooting RPC Server Problems

When you perform any of the following server-based tasks, you might receive an error that says the RPC server is unavailable:

· Replication

· Winlogon

· Enable trusted relationships

· Connect to domain controllers

· Connect to trusted domains

· User authentication

The “RPC server unavailable” error can occur for the following reasons:

· DNS problems

· Time synchronization problem

· RPC service is not running

· Network connectivity problem

Procedures for Troubleshooting RPC Server Problems

1. See “Troubleshooting Active Directory–Related DNS Problems” to identify and resolve DNS issues.

2. See “Troubleshooting Windows Time Service Problems” to identify and resolve time synchronization issues.

3. If the RPC service is not running, start the RPC service. If the RPC service is running, stop and start the RPC service.

4. Verify network connectivity and resolve any issues.

Troubleshooting NTDS Event ID 1311

NTDS Event ID 1311 occurs when the replication configuration information in Active Directory Sites and Services does not accurately reflect the physical topology of the network. The Knowledge Consistency Checker (KCC) constructs and maintains the replication topology for Active Directory. To do this, the KCC examines the sum of all naming contexts that reside in the forest as well as administrator-defined constraints for site, site link, and link cost.

An Event ID 1311 results from problems with replicating an Active Directory domain, schema, configuration, or global catalog naming contexts between domain controllers or sites. This can occur for the following reasons:

· Site link bridging is enabled on a network that does not support physical network connectivity between two domain controllers in different sites that are connected by a KCC link.

· One or more sites are not contained in site links.

· Site links contain all sites, but the site links are not interconnected. This condition is known as disjointed site links.

· One or more domain controllers are offline.

· Bridgehead domain controllers are online, but errors occur when they try to replicate a required naming context between Active Directory sites.

· Administrator-defined preferred bridgeheads are online, but they do not host the required naming contexts.

· Preferred bridgeheads are defined correctly by the administrator, but they are currently offline.

· The bridgehead server is overloaded either because the server is undersized, too many branch sites are trying to replicate changes from the same hub domain controller, or the schedules on site links or connection objects are too frequent.

· The KCC has built an alternate path around an intersite connection failure, but it continues to retry the failing connection every 15 minutes.

Procedures for Troubleshooting NTDS Event ID 1311

1. Determine if event ID 1311 is being logged on all domain controllers in the forest that hold the intersite topology generator (ISTG) role or just on site-specific domain controllers.

a. First, locate ISTG role holders by using Ldp.exe to search for the following attributes:

Base DN: CN=Sites,CN=Configuration,DC=ForestRootDomainName,DC=Com

Filter: (cn=NTDS Site Settings)

Scope: Subtree

Attributes: interSiteTopologyGenerator

b. Determine the scope of the event by checking the Directory Service event logs of all ISTG role holders in the forest, or check at least a significant number of ISTG role holders.

If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

2. See “Troubleshooting Active Directory Replication Problems” in this guide to resolve Active Directory replication failures in the forest. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

3. Determine if site link bridging is enabled and the network is fully routed. Site link bridging is enabled in Active Directory if the following conditions are true:

· The Bridge all site links check box is selected for the IP transport and the Simple Mail Transfer Protocol (SMTP) transport in Active Directory Sites and Services.

· The Options attribute for the IP transport and the SMTP transport is NULL or set to 0 (zero) for the following DN paths: CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<forest_root_domain> and CN=SMTP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<forest_root_domain>.

To determine if a fully routed network connection exists between two sites, contact your network administrator or Active Directory architect. If site link bridging is enabled in a nonrouted environment, either make the network fully routed, or disable site link bridging and then create the necessary sites links and site link bridges. For more information about creating site links, see “Link Sites for Replication” in this guide. Wait for a period of time that is twice as long as the longest replication interval in the forest. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

Note

Site link bridging is enabled by default. As a best practice, leave site link bridging enabled for fully routed networks.

4. Use the repadmin /showism command to verify that all sites are defined in site links. For each site, the output of the command will show a string of three numbers separated by colons. The numbers represent <cost>:<replication interval>:<options>. Strings with a value of “-1:0:0” indicate a possible missing site link. If this is the case, see “Link Sites for Replication” in this guide for procedures to create a replication link. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

5. Detect and remove preferred bridgeheads. Manually selecting bridgehead servers can cause event ID 1311; it is recommended that administrators do not manually select bridgehead servers. To search for preferred bridgehead servers, view the list of preferred bridgehead servers. If there are any preferred bridgehead servers, remove them from Active Directory Sites and Services, and wait for a period of time that is twice as long as the longest replication interval in the forest. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

6. Delete connections if the KCC is in “Connection Keeping” mode, and wait for a period of time that is twice as long as the longest replication interval in the forest.

Troubleshooting SceCli Event ID 1202

The presence of SceCli event ID 1202 in the application event log indicates that there might be problems with Active Directory replication, especially if the error text for this message contains a Win32 error code of either Error 1332 (0x534) or Error 1332 (0x6fc). The procedure for troubleshooting this event with either hexadecimal code is the same.

Procedure for Troubleshooting SceCli Event ID 1202

1. Enable logging for winlogon.log by changing the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\GPExtensions\<GUID name of CSE>. This creates the winlogon.log file in the %systemroot%\security\logs folder.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see “Active Directory Backup and Restore” in this guide.

2. Search the winlogon.log file for errors. At a command prompt, type the following and press ENTER:

FIND /I "error" %SYSTEMROOT%\security\logs\winlogon.log

This shows the account that is causing the problem. Determine why the account is causing the problem (for example, mistyped account, deleted account, or wrong policy was applied). If you determine that you need to remove this account from the policy, continue to the next step to determine which policy and setting to change.

3. To find which setting contains the unresolved account, type the following command at a command prompt and press ENTER:

Find /I "<account>" %systemroot%\security\templates\policies\gpt*.*

This shows the cached template from the GPO that contains the setting that is causing the problem. View the template and search for a line that begins with “GPOPath=” and the GUID of the policy you need to change.

4. Map the GUID of the problem GPO to its friendly name. Use the Gpresults.exe tool from the Windows 2000 Server Resource Kit to obtain extensive output from the computer that generated the events. Search the results for the GUID you identified from the previous step.

If you cannot find the GUID in the output from the Gpresults.exe tool, use Search.vbs. Type the following command at a command prompt and press ENTER:

Search.vbs LDAP://CN=Policies,CN=System,DC=<domain>,DC=<domain> /C:(ojbectClass=groupPolicyContainer) /P:name,displayName

5. Repair or modify the GPO, as necessary.

Troubleshooting Active Directory Installation Wizard Problems

Active Directory Installation Wizard relies on a number of systems in Windows 2000 Server, including DNS registration and resolution, LDAP query and response, Kerberos authentication, Active Directory replication, FRS replication, and the application of Group Policy objects. This section contains some general guidelines for troubleshooting problems related to the Active Directory Installation Wizard. If you detect an error in any of the event logs or commands used during troubleshooting, refer to the related topic in this chapter.

Table 2.9 shows the symptoms or errors that can occur with the Active Directory Installation Wizard, along with possible root causes and solutions.

Table 2.9   Active Directory Installation Wizard Errors

Symptom or Error	Root Cause	Solution
Network location cannot be reached.	Network connectivity problems.	Verify network connectivity.
Active Directory Installation Failed: The operation failed with the following error: The system cannot find the file specified.	This error message can be caused by one or more of the following conditions: · The default Ntds.dit file is missing or not correctly located in the %SystemRoot%\System32 folder. · Incorrect permission on the default Ntds.dit file. · Incorrect permissions on an existing NTDS folder structure.	Troubleshoot “access denied” error messages in Active Directory Installation Wizard.
The wizard cannot gain access to the list of domains in the forest. The error is: The specified domain either does not exist or could not be contacted.	This problem can occur if a domain controller in the domain has not registered an “A” record for itself in DNS.	Add the A record for the domain controller with the ipconfig /registerdns command. Flush the DNS cache on the computer running the Active Directory Installation Wizard by using the ipconfig /flushdns command. See “Troubleshooting Active Directory-Related DNS Problems” in this guide.
DCPromo fails with an “invalid parameter” error	In the Active Directory Installation Wizard, the administrator entered either a single- or multi-label NetBIOS name (such as CORP or CORP.COM) that is identical to the Active Directory domain name, or entered a name that is already in use on the network.	Use a NetBIOS name that does not conflict with other computers or domains on the network.
Error Message: The specified domain either does not exist or could not be contacted	· DNS problems might be preventing name resolution for the source domain controller. · This issue can occur because the SYSVOL directory is not shared out on the domain controller that will be used to source Active Directory.	· See “Troubleshooting Active Directory-Related DNS Problems” in this guide to resolve DNS issues. · Share out the SYSVOL directory. To verify that the SYSVOL directory is shared out, use the net share command to see if the SYSVOL share is showing. By default, the SYSVOL share is located in the following folder: %SystemRoot%\Sysvol\Sysvol.
The operation failed because: Failed to modify the necessary properties for the machine account %computername%$ “Access Denied”.	Source domain controller is not trusted for delegation.	Troubleshoot “access denied” error messages in Active Directory Installation Wizard.
The operation failed because: To perform the requested operation, the directory service needs to contact the Domain Naming Master (server <servername>). The attempt to contact it failed. The specified server cannot perform the requested operation.	Servers that are being promoted to domain controllers might generate this error message when they are unable to contact the domain naming master role holder during promotion. This happens while creating the first domain controller in a new child domain or in a new tree in an existing forest.	Troubleshoot domain naming master errors in Active Directory Installation Wizard.
Active Directory Installation Failed. The operation failed because: The Directory Service failed to create the object CN=<servername>,CN=Partitions,CN=Configuration,DC=<domain controller>.	Servers that are being promoted to domain controllers might generate this error message when they are unable to contact the domain naming master role holder during promotion.	Troubleshoot domain naming master errors in Active Directory Installation Wizard.
The replication system encountered an internal error.	See Microsoft Knowledge Base article Q267887: “Internal Error Running Dcpromo.exe.”	See Microsoft Knowledge Base article Q267887: “Internal Error Running Dcpromo.exe.”
Missing SYSVOL and NETLOGON shares	Missing NETLOGON and SYSVOL shares typically occur on additional domain controllers in an existing domain, but can also occur on the first domain controller in a new domain.	Verify that the Net Logon service is running. Also see “Troubleshooting FRS” in this guide.
An LDAP read of operational attributes failed.	The domain naming master for the forest is offline or cannot be contacted.	Make the current domain naming master accessible. If necessary, see “Seizing Operations Master Roles” in this guide.

Troubleshooting “Access Denied” Error Messages in Active Directory Installation Wizard

There are several reasons why you might receive an “Access Denied” error message while using the Active Directory Installation Wizard. All have to do with permissions on the files or file structures that are necessary for the installation and service of a domain controller.

Procedures for Troubleshooting “Access Denied” Error Messages in Active Directory Installation Wizard

1. Verify file permissions to make sure they are correct. Verify that the default Ntds.dit file permissions in the System32 folder are:

System32\Ntds.dit

BUILTIN\Users: Read [RX]

BUILTIN\Power Users: Read [RX]

BUILTIN\Administrators: Full Control [ALL]

NT AUTHORITY\SYSTEM: Full Control [ALL]

Everyone: Read [RX]

2. Verify folder permissions. If Active Directory was previously removed and now you are installing it again, the %SystemRoot%\Ntds and %SystemRoot%\Ntds\Drop folders will still exist. If permissions were changed, the error message might be caused by the folder permissions. The simplest resolution is to delete the original Ntds folder structure before running the Active Directory Installation Wizard. Or, you can change the folder permissions to match the following:

%SystemRoot%\Ntds

BUILTIN\Users: Special Access [RX]

BUILTIN\Power Users: Special Access [RWXD]

BUILTIN\Administrators: Special Access [A]

NT AUTHORITY\SYSTEM: Special Access [A]

CREATOR OWNER: Special Access [A]

%SystemRoot%\Ntds\Drop

BUILTIN\Users: Special Access [RX]

BUILTIN\Power Users: Special Access [RWXD]

BUILTIN\Administrators: Special Access [A]

NT AUTHORITY\SYSTEM: Special Access [A]

CREATOR OWNER: Special Access [A]

3. Verify that the current domain controllers in the domain have applied security policy and the Enable computer and users accounts to be trusted for delegation user right is granted to the Administrators Group.

a. In the Group Policy snap-in, click Computer Configuration, click Windows Settings, click Security Settings, click Local Policies, and then click User Rights Assignment.

b. For computers that do not have this right, confirm that Group Policy objects in the directory service and file system have replicated by looking for event ID 1704 in the application event log, and then manually apply the policy by typing the following command:

secedit /refreshpolicy machine_policy

4. Use a Dcpromo answer file to source the promotion from a deterministic domain controller. Search the Microsoft Knowledge Base for article Q223757: “Unattended Promotion and Demotion of Windows 2000 Domain Controllers.” Use the ReplicationSourceDC paramater in the answer file.

5. Verify that the source domain controller is in the domain controllers OU. The name of the source domain controller can be found in the Dcpromo.log file in the %Systemroot%\debug folder on the Windows 2000 server that you are trying to promote.

6. Open a command prompt on the source domain controller, and run the Gpresult.exe Resource Kit tool to verify that the Default Domain Controllers policy is being applied to the source domain controller.

Troubleshooting Domain Naming Master Errors in Active Directory Installation Wizard

Replication latency or replication errors can cause inconsistency in the domain naming master role owner as seen by different domain controllers in the forest.

Procedures for Troubleshooting Domain Naming Master Errors in the Active Directory Installation Wizard

1. Verify replication is functioning for the domain naming master.

2. Verify the existence of operations masters to ensure that domain controllers in the forest are consistent about the computer name that is designated as the current domain naming master.

3. View the current operations master role holders and confirm that the domain naming master is a global catalog server.

Troubleshooting Directory Data Problems

Data transactions in Active Directory are either completed in full or not made at all. If for any reason an error occurs and a transaction is unable to complete all of its steps, the system is returned to the state that existed before the transaction began. An example of an atomic transaction is an account transfer transaction where money is removed from account A and placed into account B. If the system fails after it removes the money from account A and before it places it into account B, the transaction processing system puts the money back into account A and returns the system to its original state — that is, it rolls back the transaction. Table 2.14 shows the type of directory data problems that can occur, along with root cause and solution.

Table 2.14   Directory Data Problems

Symptom	Root Cause	Solution
Lingering objects	If a domain controller remains disconnected for a longer period than the tombstone lifetime, an object that has been deleted from the directory can remain on the disconnected domain controller. For this reason, such objects are called “lingering objects.”	See “Managing Long-Disconnected Domain Controllers” in this guide.
Lost objects	If an object is created on one domain controller, and the container in which it was created is deleted on another domain controller before the object has a chance to replicate, it becomes a lost object. Lost objects are automatically placed in a domain container where you can find them and either move or delete them.	Troubleshoot lost domain objects.
Object name conflicts	If an object is created on one domain controller and an object with the same name is created in the same container on another domain controller before replication occurs, it creates an object name conflict. Active Directory automatically changes the relative distinguished name of the object with the earlier timestamp to a unique name.	Troubleshoot object name conflicts.

Troubleshooting Lost Domain Objects

In some cases, an administrator might create or move an object into a container on one domain controller and another administrator might delete that same container on a different domain controller before the object is replicated. In such cases, the object is added to the LostAndFound container for the domain. The LostAndFoundConfig container in the configuration directory partition serves the same purpose for forest-wide objects.

Procedures for Troubleshooting Lost Domain Objects

1. In Active Directory Users and Computers, on the View menu, click Advanced Features.

2. In the console tree, click the LostAndFound container.

3. For each object, examine the Last Known Parent attribute. This attribute indicates the previous location of this object.

4. For each object, do one of the following, as appropriate:

· Move the object to the correct location, recreating the parent if necessary.

· Delete the object if it is no longer needed.

5. Review and revise your operational procedures to ensure that object creations and deletions are coordinated.

Troubleshooting Object Name Conflicts

Active Directory supports multimaster replication of directory objects between all domain controllers in the domain. When replication of objects results in name conflicts (two objects have the same name within the same container), the system automatically renames one of these accounts to a unique name. For example, object ABC is renamed to be *CNF:guid, where “*” represents a reserved character, “CNF” is a constant that indicates a conflict resolution, and “guid” represents a printable representation of the objectGuid attribute value.

This will cause an event ID 12292 to be logged in the system event log on the domain controller. You must clean up Active Directory to resolve this error.

WARNING

If you find collisions in the Domain Controllers OU, stop. Continuing with the procedures below can cause further damage. Contact Microsoft Product Support Services for guidance.

Procedures for Resolving Object Name Conflicts

1. Take note of the conflicting account objects. In Active Directory Users and Computers, delete the appropriate conflicting account objects (usually the newer one) on a domain controller in the domain that contains the accounts.

2. Rename the client computers whose accounts were deleted and join them to the domain.

a. Right-click My Computer.

b. In the System Properties dialog box, select the Computer Name tab and click the Change button.

c. In the Computer Name Changes dialog box, enter a new name in the Computer name: field.

d. Click OK to exit the Computer Name Changes dialog box, and click OK to exit the System Properties dialog box.

e. Restart the computer.

3. Verify that replication is functioning properly. If replication is not functioning properly, see “Troubleshooting Active Directory Replication Problems” in this guide. If it is, review and revise your operational procedures to ensure that object creations and deletions are coordinated.

Troubleshooting Windows Time Service Problems

If you suspect a time synchronization problem, use the Net Time tool and the W32tm tool to identify time errors. Table 2.15 shows common error messages that these commands display, their root cause, and solution. If the time synchronization problem is occurring on the PDC emulator, see “Troubleshooting Windows Time Service Errors on a PDC Emulator” in this guide.

Table 2.15   Error Messages for Net Time and W32tm Tools

Tool and Error	Root Cause	Solution
Net Time: Could not locate a time server.	· The manually specified time source might not be in the local workgroup or in the domain, or it might not be announcing itself as a time server. Although you received this message, the time service might still be synchronizing time. · The time service might not have been stopped before a configuration change was made. · UDP port 123 might be closed on the firewall or router between the client and the server or it is being used by another service.	· Verify that Windows Time Service is synchronizing time. · See “Managing Windows Time Service” in this guide for best practice guidelines for configuring time. · The other service using UDP port 123 might be Windows Time Service. Stop and start Windows Time Service to solve the problem.
Net Time: Access denied.	A remote procedure call (RPC) failed to authenticate, usually because a user does not have permission to access the remote computer and run Net Time.	If you know the user name and password of an account that does have access rights, establish credentials to access the remote computer to perform this task.
W32tm: Bind failed.	Two instances of the same service are trying to start by using the same port. The Windows Time Service is already using UDP port 123 (the default port for the time service). Therefore, the W32tm tool is not able to use the port.	When you use the W32tm tool, be sure to stop and start Windows Time Service.

Troubleshooting Windows Time Service Errors on a PDC Emulator

By default, no time source is configured on the PDC emulator. As a result, when Windows Time Service is running on the PDC emulator, it sends messages to the system event log indicating that it has no time source. When this error occurs, do one of the following:

· Configure a manual time source for the PDC emulator of the forest root domain. For more information about configuring a manual time source for the PDC emulator, see “Configuring a Time Source for the Forest” in this guide.

– or –

· Set the PDC emulator to not synchronize time.

Active Directory

Operations Guide

Part II: Tasks and Procedures Appendices

Version 1.5

Developed by the Windows Resource Kits team

Microsoft Windows 2000

Microsoft Corporation

Contents

Tasks Reference. 8

Adding a New Site. 9

Adding a Subnet 9

Adding the Global Catalog to a Domain Controller and Verifying Global
Catalog Readiness. 9

Authoritative Restore of a Subtree or Leaf Object 10

Authoritative Restore of the Entire Directory. 10

Backing Up Active Directory and Associated Components. 10

Changing the Space Allocated to the Staging Area. 10

Choosing a Standby Operations Master 10

Configuring a Client to Request Time from a Specific Time Source. 11

Configuring a Reliable Time Source on a Computer Other than the
PDC Emulator 11

Configuring Site Links. 11

Configuring Time on the Forest-Root PDC Emulator 11

Creating a Site Link. 12

Creating External Trusts. 12

Creating Shortcut Trusts. 12

Decommissioning a Role Holder 12

Decommissioning Domain Controllers. 13

Designating Operations Master Roles. 13

Disabling the Windows Time Service. 13

Identifying a Global Catalog Server 13

Identifying a Site that has No Global Catalog Servers. 14

Identifying the Current Configuration of a Domain Controller 14

Installing Active Directory. 14

Moving a Domain Controller to a Different Site. 15

Moving SYSVOL Manually. 15

Moving SYSVOL with the Active Directory Installation Wizard. 16

Optimizing the Polling Interval 17

Performing a Non-Authoritative Restore. 18

Performing Active Directory Post-Installation Tasks. 18

Performing Offline Defragmentation. 18

Preparing a Domain Controller for Long Disconnection. 19

Preparing for Active Directory Installation. 20

Preventing Unauthorized Privilege Escalation. 20

Reconnecting a Long-Disconnected Domain Controller 20

Recovering a Domain Controller Through Reinstallation. 21

Reducing the Number of Client Requests Processed by the PDC Emulator 21

Regulating Directory Database Growth Caused by Tombstones. 21

Relocating Directory Database Files. 22

Relocating the Staging Area Folder 23

Removing a Lingering Object from a Global Catalog Server 23

Removing a Site. 23

Removing Lingering Objects from an Outdated Writable Domain Controller 24

Removing Manually Created Trusts. 25

Removing the Global Catalog from a Domain Controller 25

Renaming a Domain Controller 25

Restoring a Domain Controller Through Reinstallation and Subsequent
Restore from Backup. 26

Restoring and Rebuilding SYSVOL. 26

Restoring the Original Configuration of a Domain Controller 26

Seizing Operations Master Roles. 27

Updating the System Volume Path. 27

Procedures Reference. 29

Associate an Existing Subnet Object with a Site. 30

Back Up System State and the System Disk on a Domain Controller 30

Back Up System State on a Domain Controller 31

Change Polling Interval 32

Change the Delay for Initial Notification of an Intrasite Replication Partner 33

Change the Garbage Collection Logging Level 33

Change the Garbage Collection Period. 34

Change the Priority for DNS SRV Records in the Registry. 34

Change the Space Allocated to the Staging Area Folder 35

Change the Static IP Address of a Domain Controller 36

Change the Weight for DNS SRV Records in the Registry. 37

Check Directory Database Integrity. 38

Check the Status of the Shared System Volume. 38

Clean Up Metadata. 39

Clear the Global Catalog Setting. 40

Compact the Directory Database File (Offline Defragmentation) 41

Compare the Size of the Directory Database Files to the Volume Size. 44

Configure a Domain Controller as a Global Catalog Server 44

Configure a Domain Controller as a Preferred Bridgehead Server 45

Configure a Domain Controller to not be a Preferred Bridgehead Server 45

Configure DNS Server Recursive Name Resolution. 45

Configure SID Filtering. 46

Configure the DNS Client Settings. 46

Configure the Selected Computer as a Reliable Time Source. 47

Configure the Site Link Cost 47

Configure the Site Link Interval 48

Configure the Site Link Schedule. 48

Configure Time on the Forest Root PDC Emulator 49

Configure Windows NT 4.0 Emulation. 49

Copy the Directory Database Files to a Remote Share and Back. 50

Create a Connection Object 52

Create a Delegation for a New Domain Controller 53

Create a One-way Trust (MMC Method) 54

Create a One-way Trust (Netdom.exe Method) 55

Create a Secondary DNS Zone. 55

Create a Site Link Object 56

Create a Site Object 56

Create a Subnet Object 57

Create a Temporary Connection Link for Replication Partners. 57

Create a Two-way Trust (MMC Method) 58

Create a Two-way Trust (Netdom.exe Method) 60

Create the New Staging Area Folder 60

Create the SYSVOL Folder Structure. 60

Delete a Lingering Object from a Global Catalog Server 61

Delete a Server Object from a Site. 62

Delete a Site Link Object 63

Delete a Site Object 63

Delete a Subnet Object 63

Delete an Object from a Domain. 64

Determine the Database Size and Location Offline. 64

Determine the Database Size and Location Online. 64

Determine the Initial Change Notification Delay on a Domain Controller 65

Determine the ISTG Role Owner for a Site. 66

Determine the Tombstone Lifetime for the Forest 66

Determine When Intersite Replication is Scheduled to Begin. 66

Determine Whether Account Lockout Policy is Defined on a Domain. 67

Determine Whether a Domain Controller is a DNS Server 67

Determine Whether a Domain Controller is a Global Catalog Server 68

Determine Whether a Domain Controller is a Preferred Bridgehead Server 68

Determine Whether a Server Object has Child Objects. 68

Determine Whether a Site Has at Least One Global Catalog Server 69

Disable Compression on a Site Link. 69

Disable Outbound Replication. 70

Disable Time Service. 70

Flush the DNS Cache. 71

Enable Active Directory Diagnostic Event Logging. 71

Enable Change Notification on a Site Link. 71

Enable Secure Dynamic Updates for a DNS Zone. 72

Establish Credentials to Access a Remote Computer 72

Establish the Distinguished Name and GUID of an Object 73

Gather the System Volume Path Information. 74

Generate the Replication Topology. 78

Identify a Revived Lingering Object and Replication Source on a
Writable Domain Controller 79

Identify and Delete a Known Non-Replicated Lingering Object on an
Outdated Domain Controller 81

Identify Replication Partners. 81

Identify the GUID of a Domain Controller 82

Identify Unknown Lingering Objects on an Outdated Domain Controller 82

Import the SYSVOL Folder Structure. 84

Install Active Directory. 86

Install the DNS Server Service. 87

Locally Restart a Domain Controller in Directory Services Restore Mode. 87

Monitor Global Catalog Removal in Event Viewer 88

Monitor Global Catalog Replication Progress. 88

Move a Server Object to a Different Site. 89

Move the Directory Database Files to a Local Drive. 89

Perform Authoritative Restore of a Subtree or Leaf Object 93

Perform Authoritative Restore of Entire Directory. 93

Perform Directory Database Recovery. 94

Perform Semantic Database Analysis with Fixup. 94

Prepare a Domain Controller for Non-Authoritative SYSVOL Restore. 95

Purge the Ticket Cache. 96

Remotely Restart a Domain Controller in Directory Services Restore Mode. 96

Remove a Manually Configured Time Source on a Selected Computer 98

Remove a Manually Created Trust 98

Remove a Site from a Site Link. 99

Remove a Time Source Configured on the Forest-Root PDC Emulator 99

Remove Active Directory. 100

Rename a Member Server 100

Reset the Computer Account Password on the PDC Emulator 101

Restart Disabled Outbound Replication on a Domain Controller 101

Restart the Net Logon Service. 101

Restore Applicable Portion of SYSVOL from an Alternate Location. 101

Restore from Backup Media. 103

Restore from Backup Media for Authoritative Restore. 103

Restore System State to an Alternate Location. 104

Restore SYSVOL from an Alternate Location. 105

Seize the Operations Master Role. 106

Set a Manually Configured Time Source on a Selected Computer 107

Set the fRSRootPath. 107

Set the PDC Emulator to not Synchronize Time. 108

Set the Staging Area Path. 109

Set the SYSVOL Path. 110

Stop and Start Windows Time Service. 110

Start or Stop a Service. 110

Start the File Replication Service. 111

Stop the File Replication Service. 112

Stop the Net Logon Service. 112

Stop Windows NT 4.0 Emulation. 112

Synchronize Replication from a Source Domain Controller 112

Synchronize Replication Partners with the PDC Emulator 113

Transfer the Domain-Level Operations Master Roles. 113

Transfer the Forest-Level Operations Master Roles. 114

Update Security on the New SYSVOL. 115

Update the Junction Points. 116

Use the Net Time Tool 117

Use the W32tm Tool 118

Verify Active Directory Restore. 119

Verify a Connection Object 120

Verify Communication with Other Domain Controllers. 120

Verify DNS Records. 121

Verify DNS Records by Using Dcdiag.exe. 121

Verify DNS Registration and Functionality. 121

Verify Domain Membership for a New Domain Controller 122

Verify Global Catalog DNS Registrations. 122

Verify Global Catalog Readiness. 123

Verify Network Configuration. 123

Verify Network Connectivity. 124

Verify Replication is Functioning. 125

Verify an SPN.. 126

Verify Successful Replication to a Domain Controller 126

Verify that an IP Address Maps to a Subnet and Determine the
Site Association. 127

Verify that Windows Time Service is Synchronizing Time. 128

Verify the Existence of the Operations Masters. 128

View Replication Metadata of an Object 129

View the Current Operations Master Role Holders. 129

View the List of Preferred Bridgehead Servers. 130

Appendix A

Tasks Reference

This appendix lists all tasks, and pointers to their associated procedures, in alphabetical order. You can build tear sheets for your operations staff by cutting and pasting procedures into a separate document. These procedures can be part of an operations task assigned to an operator, or part of a task to troubleshoot an Active Directory component.

Adding a New Site

Use the following procedures to add a new site. Procedures are explained in detail in the linked topics.

4. Create a site object and add it to an existing site link.

5. Associate a range of IP addresses with the site, as follows:

· Create a subnet object or objects and associate them with the new site.

–or–

· Associate an existing subnet object with the new site.

6. Create a site link object, if appropriate, and add the new site and at least one other site to the site link.

7. If, while performing procedure 1, you added the new site to an existing site link temporarily in order to create the site, remove the site from that site link.

Adding a Subnet

Use the following procedures to add a subnet. Procedures are explained in detail in the linked topics.

8. Obtain the network address and subnet mask for the new subnet.

9. Create a subnet object and associate it with the appropriate site.

Adding the Global Catalog to a Domain Controller and Verifying Global Catalog Readiness

Use the following procedures to add a global catalog server to a domain controller. The procedures are explained in detail in the linked topics. Some procedures are performed only when you are configuring the first global catalog server in the site or only when Windows 2000 Server SP2 is running on the domain controller that you are configuring.

10. Stop the Net Logon service on the domain controller (SP2 only, first global catalog server in the site only).

11. Configure the domain controller as a global catalog server. Setting the Global Catalog check box initiates the process of replicating all domains to the server.

12. Monitor global catalog replication progress (first global catalog server in the site only).

13. Verify successful replication to a domain controller on the global catalog server. Check for inbound replication of all partial domain directory partitions in the forest, to ensure that all domain directory partitions have replicated to the global catalog server.

14. Verify global catalog readiness. This procedure indicates that the replication requirements have been met.

15. Restart the Net Logon service, if needed. If you are adding the first global catalog server in a site to a domain controller that is running Windows 2000 Server SP2 and you stopped the Net Logon service prior to adding the global catalog, then restart the service now.

16. Restart the global catalog server and verify global catalog DNS registrations by checking DNS for global catalog SRV resource records.

Authoritative Restore of a Subtree or Leaf Object

Use the following procedures to perform an authoritative restore of an Active Directory subtree or leaf object. Procedures are explained in detail in the linked topics.

17. Restart the domain controller in Directory Services Restore Mode (locally or remotely).

18. Restore from backup media for authoritative restore.

19. Restore system state to an alternate location.

20. Perform authoritative restore of the subtree or leaf object.

21. Restore applicable portion of SYSVOL from alternate location if necessary.

22. Verify Active Directory restore.

Authoritative Restore of the Entire Directory

Use the following procedures to perform an authoritative restore of the entire Active Directory. Procedures are explained in detail in the linked topics.

23. Restart the domain controller in Directory Services Restore Mode (locally or remotely).

24. Restore from backup media.

25. Restore system state to an alternate location.

26. Perform authoritative restore of entire directory.

27. Restore SYSVOL from alternate location.

28. Verify Active Directory restore.

Backing Up Active Directory and Associated Components

Use one of the following procedures to back up Active Directory and associated components. Procedures are explained in detail in the linked topics.

29. Back up system state.

30. Back up system state and the system disk.

Changing the Space Allocated to the Staging Area

Use the following procedures to change the amount of space that is allocated to the Staging Area folder. Procedures are explained in detail in the linked topics.

31. Stop the File Replication service.

32. Change the space allocated to the Staging Area folder.

33. Start the File Replication service.

Choosing a Standby Operations Master

Procedures are explained in detail in the linked topics.

34. Determine whether a domain controller is a global catalog server.

35. Create a connection object.

Configuring a Client to Request Time from a Specific Time Source

The following procedures allow you to specify a time source for client computers that do not automatically synchronize through the time service. Procedures are explained in detail in the linked topics.

36. Set a manually configured time source on a selected computer.

37. Remove a manually configured time source on a selected computer.

Configuring a Reliable Time Source on a Computer Other than the PDC Emulator

Although the PDC emulator in the forest root domain is the authoritative time source for that forest, you can configure a reliable time source on a computer other than the PDC emulator.

u Configure the selected computer as a reliable time source.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Configuring Site Links

Use the following procedures to configure a site link. Procedures are explained in detail in the linked topics.

38. Configure the site link schedule to identify times during which intersite replication can occur.

39. Configure the site link interval to identify how often replication polling can occur during the schedule window.

40. Configure the site link cost to establish a priority for replication routing.

41. Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate intersite replication topology generation immediately, use the following procedures to refresh the topology:

f. Determine the ISTG role owner for the site.

g. Generate the replication topology on the ISTG.

Configuring Time on the Forest-Root PDC Emulator

To configure time service for the forest-root PDC emulator, you might need to remove an external time source that you used previously, or, if you transferred that operations master role, you might only need to configure the time service on the new PDC emulator. To configure time on the forest-root PDC emulator, you can use the following procedures. Procedures are explained in detail in the linked topics.

42. Configure time on the forest-root PDC emulator.

43. Remove a time source configured on the forest-root PDC emulator.

Creating a Site Link

Use the following procedures to link sites for replication. Procedures are explained in detail in the linked topics.

44. Determine the names of the sites you are linking.

45. Create a site link object in the IP container and add the appropriate sites to it.

46. Generate the intersite topology. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate replication topology generation immediately, use the following procedures to refresh the intersite topology:

h. Determine the ISTG role owner for the site.

i. Generate the replication topology on the ISTG.

Creating External Trusts

You can create an external trust by using one of the following methods. Procedures are explained in detail in the linked topics.

47. Create a One-way Trust (MMC Method)

48. Create a One-way Trust (Netdom.exe Method)

49. Create a Two-way Trust (MMC Method)

50. Create a Two-way Trust (Netdom.exe Method)

Creating Shortcut Trusts

You can create a shortcut trust by using one of the following methods. Procedures are explained in detail in the linked topics.

51. Create a One-way Trust (MMC Method)

52. Create a One-way Trust (Netdom.exe Method)

53. Create a Two-way Trust (MMC Method)

54. Create a Two-way Trust (Netdom.exe Method)

Decommissioning a Role Holder

Procedures are explained in detail in the linked topics.

55. Verify successful replication to a domain controller.

56. Determine whether a domain controller is a global catalog server.

57. Transfer the forest-level operations master roles.

58. Transfer the domain-level operations master roles.

59. View the current operations master role holders.

Decommissioning Domain Controllers

60. View the current operations master role holders to see if any roles are assigned to this domain controller.

61. Transfer the forest-level operations master roles to another domain controller in the forest root domain if this domain controller hosts either the schema master or domain naming master roles.

62. Transfer the domain-level operations master roles if this domain controller hosts the PDC emulator, infrastructure master, or RID master.

63. Determine whether a domain controller is a global catalog server to ensure that other domain controllers are configured as global catalog servers before you remove Active Directory.

64. Verify DNS registration and functionality.

65. Verify communication with other domain controllers.

66. Verify the existence of the operations masters.

Note

If any of the verification tests fail, do not continue until you determine and fix the problems. If these tests fail, the installation is also likely to fail.

67. Remove Active Directory.

68. Determine whether a server object has child objects.

69. Delete a server object from a site.

Designating Operations Master Roles

Procedures are explained in detail in the linked topics.

70. Verify successful replication to a domain controller.

71. Determine whether a domain controller is a global catalog server.

72. Transfer the forest-level operations master roles.

73. Transfer the domain-level operations master roles.

74. View the current operations master role holders.

Disabling the Windows Time Service

You only need to perform one procedure to disable the Windows Time service.

u Disable time service.

Identifying a Global Catalog Server

Use the following procedure to determine whether a domain controller is a global catalog server. The procedure is explained in detail in the linked topic.

u To determine whether a domain controller is a global catalog server, check the properties on the NTDS Settings object of the respective server object.

Identifying a Site that has No Global Catalog Servers

Use the following procedure to determine whether a site has a global catalog server. The procedure is explained in detail in the linked topic.

u To identify a site that has no global catalog servers, determine whether the site has at least one global catalog server.

Identifying the Current Configuration of a Domain Controller

Use the following procedures to identify the current configuration of the domain controller. You need to reconfigure the current configuration on the renamed domain controller after you reinstall Active Directory.

75. Determine whether the domain controller is a global catalog server.

76. View the operations master role holders. If roles are held by this domain controller, transfer the roles to the standby operations master prior to removing Active Directory, as follows:

· If the domain controller holds any forest-level roles, transfer forest-level operations master roles.

· If the domain controller holds any domain-level roles, transfer domain-level operations master roles.

77. Determine whether the domain controller is a DNS server. Make a note of the DNS configuration so that you can reproduce it when you reinstall Active Directory.

78. Determine the initial change notification delay. If this setting has been changed from the default on this domain controller, you need to reconfigure the setting after you rename the server and add Active Directory.

79. Determine whether the domain controller is a preferred bridgehead server.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Installing Active Directory

80. Verify DNS registration and functionality.

81. Verify that an IP address maps to a subnet and determine the site association.

82. Verify communication with other domain controllers.

83. Verify the existence of the operations masters.

Note

If any of the verification tests fail, do not continue until you determine and fix the problems. If these tests fail, the installation is also likely to fail.

84. Install Active Directory.

Moving a Domain Controller to a Different Site

Use the following procedures to move a domain controller to a different site. Procedures are explained in detail in the linked topics.

85. Change the static IP address of the domain controller. This procedure includes changing all appropriate TCP/IP values, including preferred and alternate DNS servers, as well as WINS servers (if appropriate). Obtain these values from the design team.

86. Create a delegation for the domain controller, if appropriate. If the parent DNS zone of any zone that is hosted by this DNS server contains a delegation to this DNS server, use this procedure to update the IP address in all such delegations.

87. Verify that the IP address maps to a subnet and determine the site association to ensure that the subnet is associated with the site to which you are moving the server object.

88. Determine whether the server is a preferred bridgehead server.

89. If the server is a preferred bridgehead server in the current site and you do not want the server to be a preferred bridgehead server in the new site, configure the server to not be a preferred bridgehead server.

90. Move the server object to the new site.

Moving SYSVOL Manually

Except where noted, perform these steps on the domain controller that contains the system volume that you want to move. Procedures are explained in detail in the linked topics.

WARNING

This procedure can alter security settings. After you complete the procedure, the security settings on the new system volume are reset to the default settings that were established when you installed Active Directory. You must reapply any changes to the security settings on the system volume that you made since you installed Active Directory. Failure to do so can result in unauthorized access to Group Policy objects and logon and logoff scripts.

91. Identify replication partners.

92. On the replication partners, check the status of the shared system volume. You do not need to perform the test on every partner, but you need to perform enough tests to be confident that the shared system volumes on the partners are healthy.

93. Verify that replication is functioning.

94. Gather the SYSVOL path information.

95. Stop the File Replication service.

96. Create the SYSVOL folder structure.

97. Set the SYSVOL path.

98. Set the Staging Area path. If you have moved the Staging Area folder to a different location already, you do not need to do this step.

99. Set the fRSRootPath.

100. Prepare a domain controller for non-authoritative SYSVOL restore.

101. Update security on the new SYSVOL.

102. Start the File Replication service.

103. Check the status of the shared system volume.

Moving SYSVOL with the Active Directory Installation Wizard

Use the following procedures to remove and reinstall Active Directory in order to move SYSVOL. For more information about installing and removing Active Directory, see “Managing Installation and Removal of Active Directory” in this guide. Procedures are explained in detail in the linked topics.

104. View the current operations master role holders to see if any roles are assigned to this domain controller.

105. If this domain controller is listed as hosting either the schema master or domain naming master roles, then transfer the forest-level roles to another domain controller in the forest root domain. Any domain controller in the forest is capable of hosting these roles but it is recommended that they remain in the forest root domain. Ensure that you place the domain naming master role on a global catalog server.

106. If this domain controller is listed as hosting the primary domain controller (PDC) emulator, infrastructure master or relative identifier (RID) master roles, transfer the domain-level roles to another domain controller in the same domain. Do not place the infrastructure master role on a global catalog server unless all of the domain controllers host the global catalog or unless only one domain exists in the forest.

107. Determine whether a domain controller is a global catalog server and ensure that other domain controllers are configured as global catalog servers before continuing.

108. Verify DNS registration and functionality.

109. Verify communication with other domain controllers.

110. Verify the existence of the operations masters on the network.

Note

If any of the verification tests fail, do not continue until you identify and fix the problems. If these tests fail, the decommissioning operation is also likely to fail.

111. Remove Active Directory.

112. Delete the server object from a site.

113. Verify DNS registration and functionality.

Note

If the verification test fails, do not continue until you identify and fix the problems. If the test fails, then installation is also likely to fail.

114. Install Active Directory. Provide the wizard with the new location for SYSVOL when prompted.

115. Verify the site assignment for the domain controller.

116. Move a server object to a different site if the domain controller is located in the wrong site.

117. Perform final DNS configuration for a new domain controller that is located in the forest root domain:

j. Create a delegation for the new domain controller in the parent domain of the DNS infrastructure if a parent domain exists and a DNS server hosts it. If a DNS server does not host the parent domain, then follow the procedures outlined in the vendor documentation to add the delegation for the new domain controller.

k. Configure the DNS client settings.

–Or–

Perform final DNS configuration for a new domain controller that is located in a child domain:

l. Create a delegation for the new domain controller in the forest root domain.

m. Create a secondary zone.

n. Configure the DNS client settings.

118. Check the status of the shared system volume.

119. Verify DNS registration and functionality.

120. Verify domain membership for the new domain controller.

121. Verify communication with other domain controllers.

122. Verify that replication is functioning.

123. Verify the existence of the operations masters.

Optimizing the Polling Interval

You only need to perform one procedure to disable the Windows Time service.

u Change polling interval.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Performing a Non-Authoritative Restore

Use the following procedures to perform a non-authoritative restore of a domain controller. Procedures are explained in detail in the linked topics.

124. Restart the domain controller in Directory Services Restore Mode (locally or remotely).

125. Restore from backup media.

126. Verify Active Directory restore.

Performing Active Directory Post-Installation Tasks

To perform this task, the site object must already be defined in Active Directory Sites and Services and you must know the site in which you want to place the server object.

127. Determine whether a server object has child objects.

128. Verify the site assignment for the domain controller.

129. Move a server object to a different site if the domain controller is located in the wrong site.

130. Configure DNS server recursive name resolution.

131. Perform final DNS configuration for a new domain controller that is located in the forest root domain:

o. Create a delegation for the new domain controller in the parent domain of the DNS infrastructure if a parent domain exists and a Microsoft DNS server hosts it. If a Microsoft DNS server does not host the parent domain, follow the procedures outlined in the vendor documentation to add the delegation for the new domain controller.

p. Configure the DNS client settings.

– or –

Perform final DNS configuration for a new domain controller that is located in a child domain:

q. Create a delegation for the new domain controller in the forest root domain.

r. Create a secondary zone.

s. Configure the DNS client settings.

132. Check the status of the shared system volume.

133. Verify DNS registration and functionality.

134. Verify domain membership for the new domain controller.

135. Verify communication with other domain controllers.

136. Verify replication is functioning.

137. Verify the existence of the operations masters.

Performing Offline Defragmentation

Use the following procedures to perform offline defragmentation. Procedures are explained in detail in the linked topics.

138. Change the garbage collection logging level to 1. Check the Directory Service event log for event ID 1646, which reports the amount of disk space that you can recover by performing offline defragmentation.

139. Back up system state. System state includes the database file and database log files as well as SYSVOL, NETLOGON, and the registry, among other things. Always ensure that a current backup exists prior to defragmenting database files.

140. Take the domain controller offline, as follows:

· If you are logged on to the domain controller locally, restart the domain controller in Directory Services Restore Mode.

· If you are using Terminal Services for remote administration, you can remotely restart the domain controller in Directory Services Restore Mode after modifying the Boot.ini file on the remote server.

141. Compact the directory database file (offline defragmentation). As part of the offline defragmentation procedure, check directory database integrity.

142. If database integrity check fails, perform semantic database analysis with fixup.

Preparing a Domain Controller for Long Disconnection

Perform the following procedures prior to disconnecting a domain controller. Procedures are explained in detail in the linked topics.

143. Determine the anticipated length of the disconnection.

144. Determine the tombstone lifetime for the forest.

145. Determine the maximum safe disconnection period by subtracting a generous estimate of the end-to-end replication latency from the tombstone lifetime. Either find the latency estimate in the design documentation for your deployment, or request the information from a member of the design or deployment team.

· If the anticipated time of disconnection exceeds the maximum safe disconnection period, do not disconnect the domain controller. Contact a supervisor.

· If the estimated time of disconnection does not exceed the maximum safe disconnection time, proceed with disconnection.

146. View the current operations master role holders to determine whether the domain controller is an operations master role holder.

147. Transfer a domain-level operations master role, if appropriate.

148. Transfer a forest-level operations master role, if appropriate.

149. Prepare the domain controller for non-authoritative SYSVOL restore on the domain controller that you are disconnecting. This process ensures an up-to-date SYSVOL when the domain controller is restarted.

150. Synchronize replication from all inbound (source) replication partners. Each connection object below the NTDS Settings object for the server you are disconnecting represents an inbound replication partner.

151. Verify successful replication to the domain controller that you are disconnecting.

152. Label the domain controller with the date and time of disconnection and the maximum safe disconnection period.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Preparing for Active Directory Installation

To prepare for the Active Directory installation, install the DNS Server service on the server that you want to make a domain controller and gather the information that you must supply to the Active Directory Installation Wizard.

153. Install the DNS Server service.

154. Gather installation information, including:

· The user name, password, and the domain that contains the user account that you intend to use to run the Active Directory Installation Wizard.

· The name of the domain that you want the new domain controller to host.

· Location for the Active Directory database (Ntds.dit).

· Location for the log files.

· Location for the Shared System Volume (SYSVOL).

· The server administrator account name and password to use in Directory Services Restore mode.

Preventing Unauthorized Privilege Escalation

Use the following procedures to configure SID filtering. Procedures are explained in detail in the linked topics.

155. Configure SID filtering.

156. Remove SID filtering.

Reconnecting a Long-Disconnected Domain Controller

Follow these procedures to reconnect the domain controller. Procedures are explained in detail in the linked topics.

157. Determine the tombstone lifetime for the forest.

158. Determine whether the maximum safe disconnection time has been exceeded, and proceed accordingly:

· If the domain controller has been disconnected for a period that exceeds the maximum safe disconnection period, do not reconnect the domain controller. Contact a supervisor about reinstalling the domain controller.

· If the maximum safe time has not been exceeded, proceed with reconnecting.

159. If the site in which you are reconnecting the domain controller has one or more other domain controllers that are authoritative for the domain, start the domain controller at any time.

160. If the site in which you are reconnecting the domain controller has no other domain controllers that are authoritative for the domain, proceed as follows:

t. Determine when the next intersite replication cycle is scheduled to begin by viewing the replication properties on the site link that connects this site to the next closest site that includes domain controllers for this domain.

u. As soon as possible after the next replication cycle begins, start the domain controller.

161. After replication is complete, verify successful replication to the domain controller (the reconnected domain controller) of the domain, configuration, and schema directory partitions. If the domain controller is a global catalog server, check for successful replication of all domain directory partitions.

In the event that a domain controller has been disconnected for a tombstone lifetime or longer but has already replicated, follow the instructions for detecting and removing lingering objects in “Removing Lingering Objects from an Outdated Writable Domain Controller.”

Recovering a Domain Controller Through Reinstallation

Use the following procedures to recover a domain controller. Procedures are explained in detail in the linked topics.

162. Clean up metadata.

163. Reinstall Windows 2000 Server. (This procedure is not covered in this guide.)

164. Install Active Directory. During the installation process, replication occurs, ensuring that the domain controller has an accurate and up to date copy of the Active Directory. For more information about seizing operations master roles, see “Installing Active Directory” in this guide.

Reducing the Number of Client Requests Processed by the PDC Emulator

Procedures are explained in detail in the linked topics.

165. Change the weight for DNS SRV records in the registry.

166. Change the priority for DNS SRV records in the registry.

Regulating Directory Database Growth Caused by Tombstones

Use the following procedures to manage removal of tombstones following bulk deletions.

167. Change the garbage collection period to a lower interval. Decreasing the interval between garbage collections helps the system eliminate the tombstone backlog more quickly.

168. Change the garbage collection logging level to 3. Increasing the logging level to 3 causes an event that reports the number of tombstones removed each time garbage collection occurs.

169. Verify removal of tombstones in the event log. Check the Directory Service event log for NTDS event ID 1006, which reports the number of expired tombstones removed. When this event indicates that the number of tombstones removed is less than 5,000, the backlog has been cleared.

170. Change the garbage collection period. When the event ID 1006 reports a number of removed tombstones less than 5,000, you can return the interval between garbage collections to the normal level.

171. Change the garbage collection logging level, if needed. If you no longer want informational events logged for garbage collection, return the logging level to 0.

172. Compact the directory database file (offline defragmentation), if needed. Clearing the backlog does not remove the white space created by the tombstones. Only offline defragmentation returns unused disk space to the file system.

Relocating Directory Database Files

Use the following procedures to move or copy the database file, the log files, or both. Procedures are explained in detail in the linked topics.

173. Determine the location and size of the directory database files. Use the database size to prepare a destination location of the appropriate size. Track the respective file sizes during the move to ensure that you successfully move the correct files. Be sure to use the same method to check file sizes when you compare them. The size is reported differently, depending on whether the domain controller is online or offline, as follows:

· Determine the database size and location online. This size is reported in bytes.

· Determine the database size and location offline. This size is reported in megabytes (MB). Use this method if the domain controller is already started in Directory Services Restore Mode.

174. Compare the size of the directory database files to the volume size. Before moving any files in response to low disk space, verify that no other files on the volume are responsible for the condition of low disk space.

175. Back up system state. System state includes the database file and log files as well as SYSVOL and NETLOGON shared folders, among other things. Always ensure that you have a current backup prior to moving database files.

176. Restart the domain controller in Directory Services Restore Mode, as follows:

· If you are logged on to the domain controller console, locally restart the domain controller in Directory Services Restore Mode.

· If you are using Terminal Services for remote administration, modify the Boot.ini file on the remote server so that you can remotely restart the domain controller in Directory Services Restore Mode.

177. Move the database file, the log files, or both. Move the files to a temporary destination if you need to reformat the original location, or to a permanent location if you have additional disk space. Moving the files can be performed locally by using Ntdsutil.exe or remotely (temporarily) by using a file copy, as follows:

· Move the directory database files to a local drive.

· Copy the directory database files to a remote share and back. When copying any database files off the local computer, always copy both the database file and the log files.

178. If the path to the database or log files has changed, back up system state so that the restore procedure has the correct information.

Relocating the Staging Area Folder

Except where noted, perform these procedures on the domain controller that contains the Staging Area folder that you want to relocate. Procedures are explained in detail in the linked topics.

179. Identify replication partners.

180. On the replication partners, check the status of the shared system volume. You do not need to perform the test on every partner, but you need to perform enough tests to be confident that the shared system volumes on the partners are healthy.

181. Verify that replication is functioning.

182. Gather the SYSVOL path information.

183. Stop the File Replication service.

184. Create the new Staging Area folder.

185. Set the Staging Area path.

186. Prepare a domain controller for non-authoritative SYSVOL restore.

187. Start the File Replication service.

Removing a Lingering Object from a Global Catalog Server

Use the following procedures to identify and remove a read-only lingering object from a global catalog server that is running Windows 2000 Server with SP3. Procedures are explained in detail in the linked topics.

188. Establish the distinguished name and GUID of the object by searching the global catalog on an attribute that can uniquely identify the object. From the distinguished name, you can identify the domain by the DC= components.

189. Identify the GUID of a domain controller that has a writable replica of the domain of the lingering object.

190. Delete the lingering object from the global catalog server. In this procedure, use the GUID of the object and the GUID of the writable domain controller that you identify in procedures 1 and 2.

Removing a Site

Use the following procedures to remove a site. Procedures are explained in detail in the linked topics.

191. Determine whether the server object has child objects. If a child object appears, do not delete the server object. If a domain controller has been decommissioned and one or more child objects appears below the server object, replication might not have completed. If replication has completed and child objects exist, do not delete the server object. Contact a supervisor.

192. Delete the server objects within the Servers container of the site that you are removing.

193. Delete the site link object, if appropriate. Obtain this information from the design team.

194. Associate the subnet or subnets with the appropriate site, if appropriate. If you no longer want to use the IP addresses associated with the subnet object or objects, delete the subnet objects. Obtain this information from the design team.

195. Delete the site object.

196. Generate the intersite replication topology, if appropriate. By default, the KCC runs every 15 minutes to generate the replication topology. To initiate intersite replication topology generation immediately, use the following procedures to refresh the topology:

v. Determine the ISTG role owner in the site.

w. Generate the replication topology on the ISTG.

Removing Lingering Objects from an Outdated Writable Domain Controller

Use the following process to identify and remove lingering objects after you have discovered an outdated domain controller. The initial step in the process varies according to the version of Windows 2000 Server that you are using. Procedures are explained in detail in the linked topics.

197. Identify and delete the initial occurrence of a lingering object, as follows:

For Windows 2000 Server with SP2:

x. Identify a revived lingering object and its replication source on a writable domain controller. Event ID 1388 provides the distinguished name of an object that has been updated on an outdated domain controller. The message also provides the GUID of the domain controller from which the update was replicated. Use the GUID to discover the name of the source domain controller. Repeat this process on each source domain controller until you identify a source domain controller that does not have the error. This domain controller is the outdated source domain controller.

y. Disable outbound replication on the outdated source domain controller.

z. Delete the object from the outdated source domain controller.

For Windows 2000 Server with SP3:

· Identify and delete a known non-replicated lingering object on an outdated domain controller, as identified in event ID 1084. The object and source domain controller are named in the error message.

198. Identify unknown lingering objects on an outdated domain controller. This procedure requires the following series of subprocedures to be performed sequentially:

aa. Compare the directory databases of the outdated domain controller and the domain controller that received the initial replication error.

bb. Identify the distinguished names of the objects that exist on the outdated domain controller but not on the partner domain controller.

Note

The results of this procedure identify only objects where the numbers of objects did not agree between domain controllers. If numbers match but an object of a class was added on one domain controller and a different object of the same class was deleted on the other, and these changes did not replicate, this test cannot identify these inconsistent objects.

199. On the outdated domain controller, view the replication metadata of objects that you identified in the previous procedure to determine whether they were created prior to the time the domain controller was disconnected or were created during the time that the domain controller was offline. If the newest date in the Org.Time/Date column is older than the date on which the domain controller was disconnected, the object is a lingering object.

200. On the outdated domain controller, delete the objects that were created prior to the date and time that the domain controller was disconnected.

201. Restart disabled outbound replication on the outdated domain controller (SP2 only).

202. Synchronize replication from the outdated domain controller to the partner domain controller to replicate the deletions. Use the connection object on the replication partner that shows the name of the outdated domain controller in the From Server column. This procedure results in error messages on domain controllers that do not have the objects, but these messages can be ignored and will cease by the second replication cycle.

Removing Manually Created Trusts

You can remove a manually created trust by using one of the following methods. Procedures are explained in detail in the linked topics.

203. Remove a manually created trust by using the Active Directory Domains and Trusts snap-in.

204. Remove a manually created trust by using Netdom.exe.

Removing the Global Catalog from a Domain Controller

Use the following procedures to remove the global catalog from a domain controller. The procedures are explained in detail in the linked topics.

205. Clear the Global Catalog setting.

206. Monitor global catalog removal in Event Viewer.

Renaming a Domain Controller

Use the following procedures to rename a domain controller. You must perform these procedures directly on the domain controller; they cannot be performed remotely.

207. Remove Active Directory. This procedure results in the domain controller becoming a member server in the domain.

208. Rename the member server.

209. Run the Active Directory Installation Wizard. This procedure installs Active Directory on the member server to restore it to domain controller status.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup

To restore a domain controller through reinstallation and subsequently restore Active Directory from backup, you must ensure that you install Windows 2000 Server on the same drive letter and on a partition that is at least as large as the partition used before the failure. You must repartition the drive if necessary. After you reinstall Windows 2000, perform a non-authoritative restore of the system state and the system disk. Procedures are explained in detail in the linked topics.

210. Install Windows 2000 Server on the same drive letter and partition as before the failure. (This procedure is not covered in this guide.)

211. Restore from backup media.

212. Verify Active Directory restore.

Restoring and Rebuilding SYSVOL

Use these procedures only if you are working on a domain controller that does not have a functional SYSVOL. Procedures are explained in detail in the linked topics.

213. Identify replication partners.

214. Choose a partner and check the status of the SYSVOL on the partner. Because you will be copying the system volume from one of the partners, you need to make sure that the system volume you copy from the partner is up-to-date.

215. Verify that replication is functioning on the partner.

216. Restart the domain controller that is being repaired in Directory Services Restore Mode. If you are sitting at the console of the domain controller, locally restart a domain controller in directory services restore mode. If you are accessing the domain controller remotely using Terminal Services, remotely restart a domain controller in directory services restore mode.

217. Gather the SYSVOL path information.

218. Stop the File Replication service.

219. Prepare a domain controller for non-authoritative SYSVOL restore.

220. Import the SYSVOL folder structure.

221. Start the File Replication service.

222. Check the status of the shared system volume.

Restoring the Original Configuration of a Domain Controller

Use the following procedures to restore a domain controller to its original configuration.

223. Configure the domain controller as a global catalog server, if appropriate.

224. Transfer the domain operations master roles, if appropriate.

225. Transfer the forest operations master roles, if appropriate.

226. Create a delegation for the new domain controller, if appropriate. Perform this procedure in the parent domain of the domain of the DNS server, if one exists.

227. Create a secondary DNS zone, if appropriate. Perform this procedure only if the DNS server is located in a child domain, not in the forest root domain.

228. Change the delay for initial notification of an intrasite replication partner, if appropriate.

229. Configure the domain controller as a preferred bridgehead server, if appropriate.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Seizing Operations Master Roles

Procedures are explained in detail in the linked topics.

230. Verify that a complete end-to-end replication cycle has occurred. During the design process, you calculated the maximum end-to-end replication latency. The maximum end-to-end replication latency is the maximum amount of time it should take for replication to take place between the two domain controllers in your enterprise that are farthest from each other based on the topology of your network. If you verify that replication is functioning properly and wait this amount of time without making any additional changes to the directory then you can assume that all changes have been replicated and the domain controller is up to date.

231. Verify successful replication to a domain controller (the domain controller that will be seizing the role).

232. Seize the operations master role.

233. View the current operations master role holders.

Updating the System Volume Path

Use the following procedures to change the amount of space that is allocated to the Staging Area folder. Procedures are explained in detail in the linked topics.

234. Gather the System Volume path information.

235. Stop the File Replication service.

236. Set the SYSVOL path (if needed).

237. Set the fRSRootPath (if needed).

238. Set the Staging Area path (if needed).

239. Start the File Replication service.

Appendix B

Procedures Reference

This appendix lists all procedures in alphabetical order. You can build tear sheets for your operations staff by cutting and pasting the task and its procedures into a separate document.

Associate an Existing Subnet Object with a Site

Associate an existing subnet with a site under the following conditions:

u When you are removing the site to which the subnet was associated.

u When you have temporarily associated the subnet with a different site and want to associate it with its permanent site.

Requirements

u Credentials: Enterprise Admins

u Tool: Active Directory Sites and Services (Administrative Tools)

To associate an existing subnet object with a site

240. In Active Directory Sites and Services, expand the Sites container, and then click the Subnets container.

241. In the details pane, right-click the subnet with which you want to associate the site, and then click Properties.

242. In the Site box, click the site with which to associate the subnet, and then click OK.

Back Up System State and the System Disk on a Domain Controller

The following procedure backs up both system state and the system disk.

Requirements

u To back up system state, you must log on at the local computer, or you must enable Terminal Services in Remote Administration mode on the remote domain controller.

u Credentials: Domain Admins, local Administrator, or Backup Operator.

u Tool: NTBackup.exe

To back up system state and the system disk on a domain controller

243. Log on to the domain controller by using an account that has Domain Admins, local Administrator, or Backup Operator credentials.

244. Start the Windows NT Backup Wizard by choosing one of the following options:

· Open a command prompt, type ntbackup and press ENTER.

· Click Start, point to Programs, then point to Accessories, then point to System Tools, and then click Backup.

245. Click the Backup Wizard button, and then click Next.

246. Select Back up selected files, drives, or network data.

247. In Items to Back Up, click System State to select it, then expand the drive letter containing the system files and click the system disk to select it. Click Next.

248. In the Where to Store the Backup box, select the Backup Media Type by choosing one of the following options:

· Choose File if you want to back up to a file. If you do not have a tape backup unit installed, File is selected automatically.

· Choose a tape device if you want to back up to tape.

249. In the Backup Media or File Name box, choose one of the following options:

· If you are backing up to a file, type a path and file name for the backup (.bkf) file, or click the Browse button to find a folder or file. If the destination folder or file does not exist, the system creates it.

· If you are backing up to a tape unit, choose the tape that you want to use.

250. After you click Next, the Completing the Backup Wizard screen appears. This screen summarizes the options selected for this backup job. Verify that Prompt to replace data is listed in the How category. If it is not, click the Advanced button, click Next until you reach the Media Options screen, and then select Replace the data on the media with this backup.

251. Complete the remaining wizard screens, and click Finish to begin the backup operation. When a Replace Data dialog box appears, click Yes to overwrite the existing backup on this tape or file path with this backup. A progress indicator shows the status of the backup operation.

Back Up System State on a Domain Controller

The following procedure backs up only system state. It does not back up the system disk or any other data on the domain controller.

Requirements

u To back up system state, you can log on at the local computer, or you can enable Terminal Services in Remote Administration mode on the remote domain controller.

u Credentials: Domain Admins, local Administrator, or Backup Operator.

u Tool: NTBackup.exe

To back up system state on a domain controller

252. Log on to the domain controller by using an account that has Domain Admins, local Administrator, or Backup Operator credentials.

253. Start the Windows NT Backup Wizard by choosing one of the following options:

· Open a command prompt, type ntbackup and press ENTER.

· Click Start, point to Programs, then point to Accessories, then point to System Tools, and then click Backup.

254. Click the Backup Wizard button, and then click Next.

255. Select Only back up the system state data.

256. In the Where to Store the Backup box, select the Backup Media Type by choosing one of the following options:

· Choose File if you want to back up to a file. If you do not have a tape backup unit installed, File is selected automatically.

· Choose a tape device if you want to back up to tape.

257. In the Backup Media or File Name box, choose one of the following options:

· If you are backing up to a file, type a path and file name for the backup (.bkf) file, or click the Browse button to find a folder or file. If the destination folder or file does not exist, the system creates it.

· If you are backing up to a tape unit, choose the tape that you want to use.

258. After you click Next, the Completing the Backup Wizard screen appears. This screen summarizes the options selected for this backup job. Verify that Prompt to replace data is listed in the How category. If it is not, click the Advanced button, click Next until you reach the Media Options screen, and then select Replace the data on the media with this backup.

259. Complete the remaining wizard screens, and click Finish to begin the backup operation. When a Replace Data dialog box appears, click Yes to overwrite the existing backup on this tape or file path with this backup. A progress indicator shows the status of the backup operation.

Change Polling Interval

Use the following procedure to change the polling interval.

Requirements

u Credentials: Domain Admins

u Tools: w32tm.exe, regedit.exe

To change the polling interval

260. At the command prompt, type the following command and then press ENTER:

w32tm -period value

where value is one of the following:

Value	Frequency
0	Once a day
"BiDaily"	Twice a day
"Tridaily"	Three times a day
"Weekly"	Once every seven days
"SpecialSkew"	Once every 45 minutes until 3 good synchronizations occur, then once every 8 hours (3 per day) [default]
"DailySpecialSkew"	Once every 45 minutes until one good synchronization occurs, then once every day
A number equal to the number of times per day.	The number of times per day you want to synchronize

261. To make the change take effect, stop and restart the time service.

cc. At the command prompt, type the following command and then press ENTER:

net stop w32time

dd. At the command prompt, type the following command and then press ENTER:

net start w32time

262. Verify that the interval has been changed in the registry.

ee. At the command prompt, type the following command and then press ENTER:

Regedit

ff. Navigate to the following registry key and verify that the value is correct:

Hkey_Local_Machine\System\CurrentControlSet\Services\W32Time\Parameters\Period

Change the Delay for Initial Notification of an Intrasite Replication Partner

The following registry entry controls the initial change notification delay:

Replicator notify pause after modify (secs) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

The default value is 300 seconds.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe

To change the delay for initial notification of an intrasite replication partner

263. In the Run dialog box, type regedit and then click OK.

264. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS and click the Parameters entry.

265. Double-click Replicator notify pause after modify (secs) to change the initial delay.

266. In the Base box, click Decimal.

267. In the Value data box, type the number of seconds for the delay, and then click OK.

Change the Garbage Collection Logging Level

The garbage collection logging level is an NTDS Diagnostics setting in the registry.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe or Regedt32.exe (system tools)

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

To change the garbage collection logging level

268. In the Run dialog box, type regedit or regedt32, and then click OK.

269. Navigate to the Garbage Collection entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.

270. Double-click Garbage Collection, and for the Base or Radix, click Decimal.

271. In the Value data or Data box, type an integer from 0 through 5, and then click OK.

Change the Garbage Collection Period

The garbage collection period determines how often expired tombstones are removed from the directory database. This period is governed by an attribute value on the Directory Service object in the Configuration container. The default value is 12 (hours).

Decrease the period to perform garbage collection more frequently. Increase the period to perform garbage collection less frequently.

Requirements

u Credentials: Enterprise Admins

u Tools: ADSI Edit (Support Tools)

To change the garbage collection period

272. On the Start menu, point to Programs, point to Windows 2000 Support Tools, Tools, and then click ADSI Edit.

273. Expand the Configuration container and then expand CN=Configuration, expand CN=Services, and expand CN=Windows NT.

274. Right-click CN=Directory Service and then click Properties.

275. In the Select a property to view list, click garbageCollPeriod.

276. In the Edit Attribute box, type the new value.

277. Click Set and then click OK.

Change the Priority for DNS SRV Records in the Registry

To prevent clients from sending all requests to a single domain controller, the domain controllers are assigned a priority value. Clients always send requests to the domain controller that has the lowest priority value. If more than one domain controller has the same value, the clients randomly choose from the group of domain controllers with the same value. If no domain controllers with the lowest priority value are available, then the clients send requests to the domain controller with the next highest priority.

A domain controller's priority value is stored in its registry. When the domain controller starts, the Net Logon service registers with the DNS server. The priority value is registered with the rest of its DNS information. When a client uses DNS to discover a domain controller, the priority for a given domain controller is returned to the client with the rest of the DNS information. The client uses the priority value to help determine to which domain controller to send requests.

The value is stored in the LdapSrvPriority registry entry. The default value is 0 and it can range from 0 through 65535.

Note

A lower value entered for LdapSrvPriority indicates a higher priority. A domain controller with an LdapSrvPriority setting of 100 has a lower priority than a domain controller with a setting of 10. Therefore, clients attempt to use the domain controller with the setting of 100 first.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe (system tool)

To change the priority for DNS SRV records in the registry

278. In the Run dialog box, type regedit, and press ENTER.

279. In the registry editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

280. Click Edit, click New, and then click DWORD value.

281. For the new value name, type LdapSrvPriority, and press ENTER.

282. Double-click the value name that you just typed to open the Edit DWORD Value dialog box.

283. Enter a value from 0 through 65535. The default value is 0.

284. Choose Decimal as the Base option.

285. Click OK.

286. Click File, and then click Exit to close the registry editor.

Change the Space Allocated to the Staging Area Folder

This procedure outlines the steps needed to modify the registry entry that restricts the amount of disk space allocated to the Staging Area in SYSVOL.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Requirements

u Credentials: Domain or Enterprise Admins

u Tools: Regedit.exe

To change the space allocated to the Staging Area folder

287. In the Run dialog box, type regedit and press ENTER.

288. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFRS\Parameters.

289. Double-click Staging Space Limit in KB to open the Edit dialog box.

290. In the Base frame, select Decimal.

291. For Value Data enter a value from 10000 through 2000000000. Do not use commas. Click OK.

292. Close the registry editor.

Change the Static IP Address of a Domain Controller

If you change the static IP address of a domain controller, you must also change related TCP/IP settings accordingly.

Requirements

u Credentials: Administrators

u Tools: My Network Places

u Required information:

· IP address

· Subnet mask

· Default gateway address

· Preferred and alternate DNS server addresses

· WINS server addresses, if appropriate

To change the static IP address of a domain controller

293. Log on locally to the server for which you want to change the IP address.

294. On the desktop, right-click My Network Places and then click Properties.

295. In the Network and Dial-up Connections dialog box, right-click Local Area Connection and then click Properties.

296. In the Local Area Connection Properties dialog box, double-click Internet Protocol (TCP/IP).

297. In the Internet Protocol (TCP/IP) Properties dialog box, in the IP address box, type the new address.

298. In the Subnet mask box, type the subnet mask.

299. In the Default gateway box, type the default gateway.

300. In the Preferred DNS server box, type the address of the DNS server that this computer contacts.

301. In the Alternate DNS server box, type the address of the DNS server that this computer contacts if the preferred server is unavailable.

302. If this domain controller uses WINS servers, click Advanced and then, in the Advanced TCP/IP Settings dialog box, click the WINS tab.

303. If an address in the list is no longer appropriate, click the address and then click Edit.

304. In the TCP/IP WINS Server dialog box, type the new address, and then click OK.

305. Repeat steps 11 and 12 for all addresses that need to be changed, and then click OK twice to close the TCP/IP WINS Server dialog box and the Advanced TCP/IP Settings dialog box.

306. Click OK to close the Internet Protocol (TCP/IP) Properties dialog box.

Change the Weight for DNS SRV Records in the Registry

To increase client requests sent to other domain controllers relative to a particular domain controller, adjust the weight of the particular domain controller to a lower value than the others. All domain controllers start with a default weight setting of 100 and can be configured for any value from 0 through 65535, with a data type of decimal. When you adjust the weight, consider it as a ratio of the weight of this domain controller to the weight of the other domain controllers. Because the default for the other domain controllers is 100, the number you enter for weight is divided by 100 to establish the ratio. For example, if you specify a weight of 60, the ratio to the other domain controllers is 60/100. This reduces to 3/5, so you can expect clients to be referred to other domain controllers five times for every three times they get referred to the domain controller you are adjusting.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe (system tool)

To change the weight for DNS SRV records in the registry

307. In the Run dialog box, type regedit, and press ENTER.

308. In the registry editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

309. Click Edit, click New, and then click DWORD value.

310. For the new value name, type LdapSrvWeight and press ENTER. (The value name is not case sensitive.)

311. Double-click on the value name you just typed to open the Edit DWORD Value dialog box.

312. Enter a value from 0 through 65535. The default value is 100.

313. Choose Decimal as the Base option.

314. Click OK.

315. Click File, and then click Exit to close the registry editor.

Check Directory Database Integrity

Prior to performing any other troubleshooting procedures relative to a suspected database problem, or immediately following offline defragmentation, perform a database integrity check.

Requirements

u Domain controller is started in Directory Services Restore Mode

u Credentials: local Administrator account

u Tool: Ntdsutil.exe (system tool)

To check directory database integrity

316. In Directory Services Restore Mode, open a command prompt and type ntdsutil, and then press ENTER.

317. At the ntdsutil: prompt, type files and then press ENTER.

318. At the file maintenance: prompt, type integrity and then press ENTER.

319. Note the status that is reported when the integrity check is completed.

· If the integrity check completes successfully, type q and press ENTER to return to the ntdsutil: prompt. Then go to step 5 to perform semantic database analysis.

· If the integrity check reports errors, perform directory database recovery.

320. At the ntdsutil: prompt, type semantic database analysis and then press ENTER.

321. At the semantic checker: prompt, type verbose on and then press ENTER.

322. At the semantic checker: prompt, type go and then press ENTER.

323. Complete the database integrity check as follows:

· If no errors are detected in the status at the end of the procedure, type quit and then type quit again to close Ntdsutil.exe, and then restart the domain controller normally to return it to service. If you are performing this procedure remotely over a Terminal Services connection, be sure that you have modified the Boot.ini file for normal restarting before you restart the domain controller.

· If semantic database analysis reports recoverable errors, then perform semantic database analysis with fixup. If errors are not recoverable, then either restore the domain controller from backup or rebuild the domain controller.

Check the Status of the Shared System Volume

This test involves checking Event Viewer to make sure that the File Replication Service is started properly and then ensuring that the SYSVOL and NETLOGON shared folders are created.

Requirements

u Credentials: Domain Admin

u Tools: Event Viewer, net.exe

To check the status of the shared system volume

324. In Event Viewer, click File Replication Service in the Event Viewer tree to display the FRS events.

325. Look for an event 13516 with a date and time stamp that corresponds with the recent restart. It can take 15 minutes or more to appear. An event 13508 indicates that FRS is in the process of starting the service. An event 13509 indicates that the service is started successfully. Event 13516 indicates that the service is started, the folders are shared and the domain controller is functional.

326. To verify the shared folder is created, open a command prompt and type net share to display a list of the shared folders on this domain controller, including NETLOGON and SYSVOL.

327. At a command prompt, type dcdiag /test:netlogons and press ENTER.

328. Look for a message that states computername passed test NetLogons where computername is the name of the domain controller. If you do not see the test passed message, some problem will prevent replication from functioning. This test verifies that the proper logon privileges are set to allow replication to occur. If this test fails, verify the permissions set on the NETLOGON and SYSVOL shared folders.

Clean Up Metadata

If you give the new domain controller the same name as the failed computer, then you need perform only the first procedure to clean up metadata, which removes the NTDS Settings object of the failed domain controller. If you will give the new domain controller a different name, then you need to perform all three procedures: clean up metadata, remove the failed server object from the site, and remove the computer object from the domain controllers container.

Requirements

u Credentials: Enterprise Admins (metadata cleanup requires modifying the configuration naming context)

u Tool: Ntdsutil.exe, Active Directory Sites and Services, Active Directory Users and Computers

To clean up metadata

329. At the command line, type ntdsutil and press ENTER.

330. At the ntdsutil: prompt, type metadata cleanup and press ENTER.

331. At the metadata cleanup: prompt, type connections and press ENTER.

332. At the server connections: prompt, type connect to server servername, where servername is the domain controller (any functional domain controller in the same domain) from which you plan to clean up the metadata of the failed domain controller. Press ENTER.

333. Type quit and press ENTER to return you to the metadata cleanup: prompt.

334. Type select operation target and press ENTER.

335. Type list domains and press ENTER. This lists all domains in the forest with a number associated with each.

336. Type select domain number, where number is the number corresponding to the domain in which the failed server was located. Press ENTER.

337. Type list sites and press ENTER.

338. Type select site number, where number refers to the number of the site in which the domain controller was a member. Press ENTER.

339. Type list servers in site and press ENTER. This will list all servers in that site with a corresponding number.

340. Type select server number and press ENTER, where number refers to the domain controller to be removed.

341. Type quit and press ENTER. The Metadata cleanup menu is displayed.

342. Type remove selected server and press ENTER.

At this point, Active Directory confirms that the domain controller was removed successfully. If you receive an error that the object could not be found, Active Directory might have already removed from the domain controller.

343. Type quit, and press ENTER until you return to the command prompt.

If the new domain controller receives a different name than the failed domain controller, perform the following additional steps:

Note

Do not perform the additional steps if the new computer will have the same name as the failed computer. Ensure that hardware failure was not the cause of the problem. If the faulty hardware is not changed, then restoring through reinstallation might not help.

To remove the failed server object from the sites

344. In Active Directory Sites and Services, expand the appropriate site.

345. Delete the server object associated with the failed domain controller.

To remove the failed server object from the domain controllers container

346. In Active Directory Users and Computers, expand the domain controllers container.

347. Delete the computer object associated with the failed domain controller.

Clear the Global Catalog Setting

Clearing the Global Catalog setting initiates removal of the partial directory partitions from the directory database of the domain controller.

Requirements

u Credentials: Domain Admins in the domain of the global catalog server

u Tools: Active Directory Sites and Services (Administrative Tools)

To clear the Global Catalog setting

348. In Active Directory Sites and Services, expand the Sites container and then expand the site in which you are removing a global catalog server.

349. Expand the Servers container and then expand the server object for the domain controller that you want to remove as a global catalog server.

350. Right-click the NTDS Settings object for the target server, and then click Properties.

351. If the Global Catalog check box is selected, clear the check box and then click OK.

Compact the Directory Database File (Offline Defragmentation)

Performing offline defragmentation creates a new, compacted version of the database file in a different location. This location can be either on the same computer or a network-mapped drive. However, to avoid potential problems related to network issues, perform this procedure locally.

After compacting the file to the temporary location, copy the compacted Ntds.dit file back to the original location. If possible, maintain a copy of the original database file that you have either renamed in its current location or copied to an archival location.

Requirements

u Domain controller is started in Directory Services Restore Mode.

u Credentials:

· Local domain controller: local Administrator account.

· Remote location: Read and write permissions on the destination drive and shared folder.

u Disk space:

· Current database drive: Free space on the drive that contains the file equivalent to at least 15 percent of the current size of the database for temporary storage during the index rebuild process.

· Destination database drive: Free space equivalent to at least the current size of the database for storage of the compacted database file.

u Tools:

· Command line: net use, del, copy commands

· Ntdsutil.exe (system tool)

To perform offline defragmentation of the directory database

352. In Directory Services Restore Mode, compact the database file to a local directory or remote shared folder, as follows:

· Local directory: Go to step 2.

· Remote directory: If you are compacting the database file to a shared folder on a remote computer, establish a network connection to the shared folder as shown below. Because you are logged on as the local Administrator, unless permissions on the shared folder include the built-in Administrator account, you must provide a domain name, user name, and password for a domain account that has write permissions on the shared folder. In the example below, \\SERVER1\NTDS is the name of the shared folder, and K: is the drive that you are mapping to the shared folder. Example text that describes information that you type is shown in bold. After typing the first line and pressing ENTER, Ntdsutil.exe prompts you for the password. Type the password and then press ENTER.

H:\>net use K: \\SERVER1\NTDS /user:domainName\userName *

Type the password for \\SERVER1\NTDS:

Drive K: is now connected to \\SERVER1\NTDS

The command completed successfully.

353. At the command prompt, type ntdsutil and then press ENTER.

354. At the ntdsutil: prompt, type files and then press ENTER.

355. At the file maintenance: prompt, type

compact to drive:\localDirectoryPath and then press ENTER

where drive:\ LocalDirectoryPath is the path to a location on the local computer. If you have mapped a drive to a shared folder on a remote computer, type the drive letter only (for example, compact to K:\).

Note

When compacting to a local drive, you must provide a path. If the path contains any spaces, enclose the entire path in quotation marks (for example, compact to "c:\new folder"). If the directory does not exist, Ntdsutil.exe creates it and creates the file named Ntds.dit in that location.

356. If defragmentation completes successfully, type quit and press ENTER to quit the file maintenance: prompt. Type quit and press ENTER again to quit Ntdsutil.exe. Go to step 6.

If defragmentation completes with errors, go to step 9.

Caution

Do not overwrite the original Ntds.dit file or delete any log files

357. If defragmentation succeeds with no errors, then follow the Ntdsutil.exe onscreen instructions to:

gg. Delete all of the log files in the log directory by typing

del drive:\pathToLogFiles\*.log

Note

You do not need to delete the edb.chk file.

hh. If space allows, either rename the original Ntds.dit file to preserve it or else copy it to a different location. Avoid overwriting the original Ntds.dit file.

ii. Manually copy the compacted database file to the original location, as follows:

copy temporaryDrive:\ntds.dit originalDrive:\pathToOriginalDatabaseFile\ntds.dit

For example, if the original location is H:\NTDS and you compacted the file to K:\NTDS, you would type:

copy k:\ntds\ntds.dit h:\pathToOriginalDirectory\ntds\ntds.dit

358. Type ntdsutil and then press ENTER.

359. At the ntdsutil: prompt, type files and then press ENTER.

360. At the file maintenance: prompt, type integrity and then press ENTER.

If the integrity check fails, the likely cause is that an error occurred during the copy operation in step 6.c. Repeat steps 6.c. through step 9. If the integrity check fails again:

· Contact Microsoft Product Support Services.

-Or-

· Copy the original version of the Ntds.dit file that you preserved in step 6.b. to the original database location and repeat the offline defragmentation procedure.

361. If the integrity check succeeds, proceed as follows:

· If the initial compact to command failed, go to step 4 and perform steps 4 through 9.

· If the initial compact to command succeeded, type quit and press ENTER to quit the file maintenance: prompt, and then repeat to quit Ntdsutil.exe.

362. Restart the domain controller normally. If you are connected remotely through a Terminal Services session, be sure that you have modified the Boot.ini file for normal restarting before you restart the domain controller.

If errors appear when you restart the domain controller:

363. Restart the domain controller in Directory Services Restore Mode.

364. Check the errors in Event Viewer.

If the following events are logged in Event Viewer on restarting the domain controller, respond to the events as follows:

· 1046: “The Active Directory database engine caused an exception with the following parameters.” In this case, Active Directory cannot recover from this error and you must restore from backup media.

· 1168: “Internal error: An Active Directory error has occurred.” In this case, information is missing from the registry and you must restore from backup media.

365. Check database integrity and then proceed as follows:

If the integrity check fails, try repeating step 6.c through step 9 above, and then repeat the integrity check. If the integrity check fails again:

· Contact Microsoft Product Support Services.

-Or-

· Copy the original version of the Ntds.dit file that you preserved in step 6.b. to the original database location and repeat the offline defragmentation procedure.

If the integrity check succeeds, perform semantic database analysis with fixup.

366. If semantic database analysis with fixup succeeds, quit Ntdsutil.exe and restart the domain controller normally.

367. If semantic database analysis with fixup fails, contact Microsoft Product Support Services.

Compare the Size of the Directory Database Files to the Volume Size

You might need to relocate the database file, the log files, or both if disk space on the volume on which they are stored becomes low. Before moving the database file or log files, examine the size of the database folder, logs folder, or both if they are stored in the same location, relative to the size of the volume to verify that these files are the cause of low disk space. Include the size of the SYSVOL folder if it is on the same partition.

Requirements

u Credentials: Domain Users (online) or local Administrator (offline)

u Tool: Command line: dir command

To compare the size of the directory database file files to the volume size

368. In Windows Explorer, click My Computer.

369. On the View menu, click Details.

370. In the Name column in the details pane, locate the volume. Make a note of the value in the Total Size column.

371. Navigate to the folder that stores the database file, the log files, or both.

372. Right-click the folder and then click Properties. Make a note of the value in Size on disk.

373. If the volume includes SYSVOL, navigate to that folder and repeat step 5.

374. Compare the sizes. If the combined size of the relevant database files and SYSVOL files (if appropriate) is significantly smaller than the volume size, then check the contents of the volume for other files.

375. If other files are present, move those files and reassess the disk space on the volume.

Configure a Domain Controller as a Global Catalog Server

Use the setting on the NTDS Settings object to indicate whether a domain controller is designated as a global catalog server.

Requirements

u Credentials: Domain Admins in the domain of the global catalog server

u Tools: Active Directory Sites and Services (Administrative Tools)

To configure a domain controller as a global catalog server

376. In Active Directory Sites and Services, expand the Sites container and then expand the site in which you are designating a global catalog server.

377. Expand the Servers container and then expand the server object for the domain controller that you want to designate as a global catalog server.

378. Right-click the NTDS Settings object for the target server, and then click Properties.

379. Select the Global Catalog check box and then click OK.

Configure a Domain Controller as a Preferred Bridgehead Server

You can configure a domain controller as a preferred bridgehead server by modifying an attribute of the server object.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To configure a domain controller as a preferred bridgehead server

380. In Active Directory Sites and Services, expand Sites, and expand the site in which the server object is located.

381. Expand the Servers container to display the servers that are currently configured for that site.

382. Right-click the server object for the domain controller and then click Properties.

383. In the Transports available for intersite data transfer box, click IP, click Add, and then click OK.

The domain controller is now configured as a preferred bridgehead server. Be sure to configure more than one bridgehead server for each domain that is represented in the site.

Configure a Domain Controller to not be a Preferred Bridgehead Server

Use the server object properties to remove a preferred bridgehead server from the IP transport.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To configure a domain controller to not be a preferred bridgehead server

384. In Active Directory Sites and Services, expand the Sites container and expand the site of the preferred bridgehead server.

385. Expand the Servers node to display the list of domain controllers currently configured for that site.

386. Right-click the server you want to remove and then click Properties.

387. If IP appears in the list that marks this server as a bridgehead server for the IP transport, click IP, click Remove, and then click OK.

Configure DNS Server Recursive Name Resolution

Configure DNS server recursive name resolution based on the recursive name resolution method established on your network.

Requirements

u Credentials: Domain Admin

u Tools: DNS snap-in

To configure DNS server recursive name resolution

388. If your network uses root hints as the name resolution method, you do not need to perform any additional options. Root hints are automatically configured during installation. Do not continue to step 2.

389. If you need to configure forwarders, open the DNS snap-in and continue to step 3.

390. In the console tree, right-click computer_name (where computer_name is the computer name of the domain controller), and then click Properties.

391. In the domain_controller Properties sheet (where domain_controller is the name of the domain controller), on the Forwarders tab, select the Enable forwarders check box.

392. In the IP address box, type ip_address (where ip_address is the IP address of the DNS server or nearest replication partner, from which the domain is delegated), click Add, and then click OK.

Configure SID Filtering

The administrator of the trusting domain applies SID filtering to filter out migrated SIDs stored in SIDHistory from specific domains. For example, where an external trust relationship exists so that the noam domain trusts the acquired domain, an administrator of the noam domain can apply SID filtering to the acquired domain, which allows all SIDs with a domain SID from the acquired domain to pass, but all other SIDs (such as those from migrated SIDs stored in SIDHistory) to be discarded.

Requirements

u Credentials: Domain Admins of trusting domain.

u Tool: Netdom.exe (Support tools)

To apply SID filtering

393. Log on to the trusting domain with an account with domain administrator credentials.

394. At the command prompt, type the following:

netdom /filtersids trusteddomain

where trusteddomain is the domain whose SIDs you want to filter. Press ENTER.

To remove SID filtering

395. Log on to the trusting domain with an account with domain administrator credentials.

396. At the command prompt, type the following:

netdom /filtersids no trusteddomain

where trusteddomain is the trusted domain where you had previously applied SID filtering, which you now want to remove. Press ENTER.

Configure the DNS Client Settings

Configure the DNS client settings on the new domain controller.

Requirements

u Credentials: Domain Admin

u Tools: My Network Places

To Configure the DNS Client Settings

397. Open the Properties dialog box for My Network Places.

398. In the Network and Dial-up Connections dialog box, right click the connection that represents the connection this computer uses to attach to your network. The default label is Local Area Connection but this can be changed so it might not be labeled the same on your computer. Click Properties.

399. In the Local Area Connection Properties dialog box, click once on the Internet Protocol (TCP/IP) to highlight it (ensure you do not clear the check box in front of it) then click Properties.

400. In the Internet Protocol (TCP/IP) Properties dialog box, ensure that Use the following DNS server addresses: is selected.

401. If the new domain controller is located in the forest root domain, set the Preferred DNS server IP address to that of another DNS server in the forest root domain. Try to choose a server that is located near the new domain controller. Set the Alternate DNS server address to the IP address of the new domain controller (so that it is referencing itself).

If the new domain controller is located in a child domain, set the Preferred DNS server IP address to the IP address of the new domain controller (so that it is referencing itself). Set the Alternate DNS server address to that of another DNS server in the same domain. Try to choose a server that is located near the new domain controller.

402. Click OK to close the dialog box.

Configure the Selected Computer as a Reliable Time Source

Perform the following procedure on the selected computer to configure it as a reliable time source.

Requirements

u Credentials: Domain Admins

u Tools: regedit.exe

To configure the selected computer as a reliable time source

403. At the command prompt, type the following command and then press ENTER:

Regedit

404. Navigate to the following registry key and change the value to 1:

Hkey_Local_Machine\System\CurrentControlSet\Services\W32Time\Parameters\ReliableTimeSource

Configure the Site Link Cost

When creating or modifying site links, use the object properties to configure the relative cost of using the site link. Obtain the cost value from the design team.

Requirements

u Credentials: Enterprise Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To configure site link cost

405. In Active Directory Sites and Services, expand the Sites container and the Inter-Site Transports container, and then click the IP container.

406. In the details pane, right-click the site link object you want to configure, and then click Properties.

407. In the Cost box, specify the number for the comparative cost of using the site link, and then click OK.

Configure the Site Link Interval

Use the properties on the site link object to determine how often during the available replication schedule you want bridgehead servers to poll their intersite replication partners for changes. Obtain the interval value from the design team.

Requirements

u Credentials: Enterprise Admins.

u Tools: Active Directory Sites and Services (Administrative Tools)

To configure the site link interval

408. In Active Directory Sites and Services, expand the Sites container and the Inter-Site Transports container, and then click the IP container.

409. In the details pane, right-click the site link object you want to configure, and then click Properties.

410. In the Replicate every _____ minutes box, specify the number of minutes for the intervals at which replication polling occurs during an open schedule, and then click OK.

Configure the Site Link Schedule

Use the properties on the site link object to define when replication is allowed. Obtain the schedule from the design team.

Requirements

u Credentials: Enterprise Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To configure the site link schedule

411. In Active Directory Sites and Services, expand the Sites container and the Inter-Site Transports container, and then click the IP container.

412. In the details pane, right-click the site link object you want to configure, and then click Properties.

413. In the SiteLinkName Properties dialog box, click Change Schedule.

414. In the Schedule for SiteLinkName dialog box, select the block of days and hours during which you want replication to occur or not occur (available or not available), and then click the appropriate option.

415. Click OK twice.

Configure Time on the Forest Root PDC Emulator

Use the following procedure to configure the time service on the forest-root PDC emulator. Perform the procedure on the PDC emulator.

Requirements

u Credentials: Domain Admins or Local Administrator on the PDC emulator.

u Tools: net time, w32tm.exe, ping

To configure time on the forest-root PDC Emulator

416. Ping the Simple Network Time Protocol (SNTP) server to ensure that it is reachable from the client. Type the following command and then press ENTER:

ping server

where server is the DNS name or IP address of the SNTP server.

417. Open UDP 123 port for outgoing traffic on firewall if needed.

418. Open UDP 123 port (or a different port you have selected) for incoming SNTP traffic.

419. At the command prompt, type the following command and then press ENTER:

w32tm -portnumber

where portnumber is the server port specified in step 3.

420. At the command prompt, type the following command and then press ENTER:

net time /setsntp:server

where server is the DNS name or IP address of the SNTP server.

421. To verify that the manually configured time source has been set, at the command prompt, type the following command and then press ENTER:

net time /querysntp

Verify that the name of the SNTP server is displayed.

422. To make the change take effect, stop and restart the time service.

jj. At the command prompt, type the following command and then press ENTER:

net stop w32time

kk. At the command prompt, type the following command and then press ENTER:

net start w32time

Configure Windows NT 4.0 Emulation

Use this procedure to set the registry for Windows NT 4.0 emulation.

Requirements

Credentials: Domain Admins

Tools: Regedt32

To configure Windows NT 4.0 emulation

423. In Regedt32, locate the NT4Emulator entry for the following subkey in the registry:

HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Netlogon/Parameters

424. On the Edit menu, click REG_DWORD, type 0x1, and then click OK.

425. Quit Registry Editor.

Copy the Directory Database Files to a Remote Share and Back

If you need to move the database file or the log files while you reconfigure the drive on which they are currently stored, and you do not have sufficient space to move the files locally, then you can use xcopy to copy the files to a remote shared folder temporarily, and then use the same procedure to copy them back to the original drive. You can use this method as long as the path to the files does not change. You cannot use Ntdsutil.exe to move database files off the local computer.

Important

When relocating any database files (the database file or the log files) off the local computer, always copy both the database file and the log files so that all of the necessary files to restore the directory service are maintained.

Requirements

u Domain controller is started in Directory Services Restore Mode.

u Credentials: local Administrator account.

u Shared folder on a remote drive that has enough free space to hold the database file (Ntds.dit) and log files. Create separate subdirectories for copying the database file and the log files.

u Disk space:

· Temporary location: Free space on the destination drive equivalent to at least the current combined size of the database file or log files, depending on what files you are moving.

· Permanent location: Free space on the destination NTFS drive equivalent to at least the following sizes, plus space to accommodate anticipated growth of the environment, depending on what files you are moving:

Caution

The drive that is the permanent location of the database or log files must be formatted as NTFS.

Database file only: The size of the database file plus 20 percent of the Ntds.dit file or 500 MB, whichever is greater.

Log files only: The size of the combined log files plus 20 percent of the combined logs or 500 MB, whichever is greater.

Database and logs. If the database and log files are stored on the same partition, free space equal to at least 20 percent of the combined Ntds.dit and log files, or 1 GB, whichever is greater.

Important

The preceding levels are minimum recommended levels. If you follow monitoring recommendations, falling below these minimum levels generates an alert. Therefore, adding additional space according to anticipated growth is recommended.

u Tools:

· Command line: net use, dir, xcopy commands

· Ntdsutil.exe (system tool)

To copy the directory database and log files to a remote drive and back to the local computer

426. In Directory Services Restore Mode, open a command prompt and change directories to the current location of the database file (Ntds.dit) or the log files. If the database file and log files are in different locations, perform step 2 for each directory.

427. Run the dir command and make a note of the current size and location of the Ntds.dit file and the log files.

428. Establish a network connection to a shared folder, as shown below. Because you are logged on as the local Administrator, unless permissions on the shared folder include the built-in Administrator account, you must provide a domain name, user name, and password for an account that has write permissions on the shared folder.

In the example below, \\SERVER1\NTDS is the name of the shared folder. K: is the drive that you have mapped to the shared folder. Example text that describes information that you type is shown in bold. After typing the first line and pressing ENTER, Ntdsutil.exe prompts you for the password. Type the password and then press ENTER.

H:\>net use K: \\SERVER1\NTDS /user:domainName\userName *

Type the password for \\SERVER1\NTDS:

Drive K: is now connected to \\SERVER1\NTDS

The command completed successfully.

429. Use the xcopy command to copy the database file and log files to the location you established in step 3. In the example where the database file is located in H:\WINNT\NTDS and the share has the subdirectory DB, the text you type is shown in bold:

H:>xcopy WINNT\NTDS K:\DB

The command copies the contents of WINNT\NTDS to the subfolder DB in the shared folder described as drive K:. If the database file and log files are in different locations, repeat the xcopy command for the log files, specifying the subfolder for the log files.

430. Change drives to the new location and run the dir command to compare the file sizes to those listed in step 2. Use this step to ensure that you copy the correct set of files back to the local computer.

431. At this point, you can safely destroy data on the original local drive.

432. After the destination drive is prepared, re-establish a connection to the network drive as described in step 3, if necessary.

433. Copy the database and log files from the remote shared folder back to the original location on the domain controller.

434. At the command prompt, type ntdsutil and then press ENTER.

435. At the ntdsutil: prompt, type files and then press ENTER.

436. At the file maintenance: prompt, type integrity and then press ENTER.

If the integrity check fails, perform semantic database analysis with fixup.

437. If the integrity check succeeds, type quit and press ENTER to quit the file maintenance: promp. Type quit and press ENTER again to quit Ntdsutil.exe.

438. Restart the domain controller normally. If you are performing this procedure remotely over a Terminal Services connection, be sure that you have modified the Boot.ini file for normal restarting before you restart the domain controller.

If errors appear when you restart the domain controller:

439. Restart the domain controller in Directory Services Restore Mode.

440. Check the errors in Event Viewer.

If the following events are logged in Event Viewer on restarting the domain controller, respond to the events as follows:

· 1046: “The Active Directory database engine caused an exception with the following parameters.” In this case, Active Directory cannot recover from this error and you must restore from backup media.

· 1168: “Internal error: An Active Directory error has occurred.” In this case, information is missing from the registry and you must restore from backup media.

Create a Connection Object

To help ensure that the current role holder and the standby operations master are replication partners, you can manually create a connection object between the two domain controllers. Even if a connection object is generated automatically, it is recommended that you manually create one. The system can alter automatically created connection objects at any time. Manually created connections remain the same until an administrator changes them.

You must know the current operations master role holder to perform the following procedure. For information about determining the current operations master role holders, see “View the Current Operations Master Role Holders” earlier in this guide.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To create a connection object on the current operations master

441. In Active Directory Sites and Services snap-in, in the console tree in the left pane, expand the Sites folder to see the list of available sites.

442. Expand the site name in which the current role holder is located to display the Servers folder.

443. Expand the Servers folder to see a list of the servers in that site.

444. Expand the name of the server that is currently hosting the operations master role to display NTDS Settings.

445. Right-click NTDS Settings, click New, and then click Connection.

446. In the Find Domain Controllers dialog box, select the name of the standby operations master then click OK.

447. In the New Object-Connection dialog box, enter an appropriate name for the connection object or accept the default name and click OK.

To create a connection object on the standby operations master

448. Expand the site name in which the standby operations master is located to display the Servers folder.

449. Expand the Servers folder to see a list of the servers in that site.

450. Expand the name of the server that you want to be the standby operations master to display its NTDS Settings.

451. Right-click NTDS Settings, click New, and then click Connection.

452. In the Find Domain Controllers dialog box, select the name of the current role holder, then click OK.

453. In the New Object-Connection dialog box, enter an appropriate name for the connection object or accept the default name and click OK.

Create a Delegation for a New Domain Controller

This procedure creates a delegation for a new domain controller that is also a DNS server in the parent DNS domain. If your forest root domain has a parent DNS domain, perform these steps on a DNS server in the parent domain. If you just added a new domain controller to a child domain, perform these steps on a DNS server in the DNS parent domain. By following recommended practices, the parent domain is the forest root domain.

Requirements

u Credentials: Domain Admin

u Tools: DNS Management Console

To create a delegation for a new domain controller

454. From the DNS snap-in, navigate to child_domain (where child_domain is the name of the child domain) in the console tree.

455. In the console tree, right-click child_domain, and then click Properties.

456. In the child_domain Properties sheet, on the Name Servers tab, click Add.

457. In the New Resource Record dialog box, in the Server name box, type child_dc.child_domain.parent_domain (where child_dc is the name of the new domain controller, child_domain is the name of the child domain, and parent_domain is the name of the parent domain).

458. In the New Resource Record dialog box, in the IP address box, type ip_address (where ip_address is the IP address of the child domain controller), click Add, and then click OK.

Create a One-way Trust (MMC Method)

For the following two procedures, a member of Domain Admins in the trusted domain performs the first procedure and a member of Domain Admins in the trusting domain performs the second procedure.

To create a one-way trust relationship in the trusted domain

459. With the administrator of the other domain, agree on a secure channel password to be used in establishing the trust.

460. In the trusted domain, log on as a member of Domain Admins.

461. In Active Directory Domains and Trusts, expand the domain tree until the trusted domain name appears, and then right-click the trusted domain node.

462. Click Properties, and then click the Trusts tab.

463. Next to the Domains that trust this domain box, click Add.

464. In the Trusting domain box, type the trusting domain name. If you are adding a Windows 2000 domain, type the full DNS name (noamreskit.com in this example). If the domain is running an earlier version of Windows, type the domain name (noam in this example.)

465. In the Password box, type the agreed-upon password.

466. In the Confirm password box, retype the password, and then click OK.

467. A message appears that says the trust cannot be verified. Click OK.

Note

The reason for this error is that Windows 2000 is attempting to verify the secure channel. It cannot verify the secure channel at this time because the other side of the trust is not yet created.

468. Click OK to close the Properties sheet.

To create a one-way trust relationship in the trusting domain

469. In the trusting domain, log on as a member of Domain Admins.

470. In Active Directory Domains and Trusts, expand the domain tree until the trusting domain name appears, and then right-click the trusting domain node.

471. Click Properties, and then click the Trusts tab.

472. Next to the Domains trusted by this domain box, click Add.

473. In the Trusted domain box, type the trusted domain name. If you are adding a Windows 2000 domain, type the full DNS name (acquired.com in this example). If the domain is running an earlier version of Windows, type the domain name (acquired in this example).

474. In the Password box, type the agreed-upon password.

475. In the Confirm password box, retype the password, and then click OK.

476. A message appears that says the trusted domain has been added and the trust verified. Click OK.

477. A message appears asking if you want to verify the trust. Click Yes, and then click OK.

478. Click OK to close the Properties sheet.

Note

If the trust is successfully created in both domains, click Yes to verify the trust. If the trust is been created in the trusted domain, clicking Yes returns an error. When the trust is created in trusted domain, the trust takes effect. You do not need to verify the trust for the trust to take effect.

Create a One-way Trust (Netdom.exe Method)

For the following procedure, you create both sides of the one-way trust with one command. You must have the domain administrator passwords for both domains.

To create a one-way trust using Netdom.exe

u Open a command prompt and type the following command:

netdom trust /d:trusteddomain trustingdomain /add

where trusteddomain is the trusted domain, and trustingdomain is the trusting domain. If the domain is Windows 2000, use the full DNS name; if it is Windows NT 4.0, use the domain name. Press ENTER

You may enter the administrator passwords, using Pd: for the trusted domain password and Po: for the trusting domain password. If you do not enter the passwords, you will be prompted for them.

Example:

netdom trust /d:acquired.com noam.com /add

/Ud:acquired.com\admin /Pd:xxxx

/Uo:noam.com\admin /Po:yyyy

Create a Secondary DNS Zone

Perform this procedure only on DNS servers that are located in the child domain, not the forest root domain. Perform these steps on the new domain controller.

Requirements

u Credentials: Domain Admin

u Tools: DNS snap-in

To create a secondary DNS zone

479. In the DNS snap-in, right-click the new domain controller in the console tree and select New Zone.

480. In the New Zone wizard, click Next to continue.

481. Select Standard secondary as the Zone Type. Click Next.

482. Ensure that Forward lookup zone is selected. Click Next.

483. For Zone Name, enter _msdcs.forestrootdomain where forestrootdomain is the fully qualified domain name of the forest root domain. Click Next.

484. In the Master DNS Servers dialog box, enter IP address of at least two DNS servers in the forest root domain. Click Next.

485. Review the settings you defined and click Finish to close the wizard.

Create a Site Link Object

To link sites for replication, create a site link object in the container for the intersite transport that will replicate the site, and add the sites to it.

Requirements

u Credentials: Enterprise Admins

u Tool: Active Directory Sites and Services (Administrative Tools)

To create a site link object

486. In Active Directory Sites and Services, expand the Sites container and then the Inter-Site Transports container.

487. Right-click the IP container, and then click New Site Link.

488. In the Name box, type a name for the site link.

489. In the Sites not in this site link box, click a site that you want to add to the site link. Hold down the Shift key to click a second site that is adjacent in the list, or the Ctrl key to click a second site that is not adjacent in the list.

490. After selecting all of the sites that you want added to the site link, click Add, and then click OK.

Create a Site Object

To create a new site, you must create a site object and add it to a site link.

Requirements

u Credentials: Enterprise Admins

u Tool: Active Directory Sites and Services (Administrative Tools)

To create a site object

491. In Active Directory Sites and Services, right-click the Sites container and then click New Site.

492. In the Name box, type the name of the site.

493. In the Link Name list, click a site link for this site, and then click OK.

494. In the Active Directory message box, read the information and then click OK.

Create a Subnet Object

To create a subnet object, you must have the following information:

u The site to which the subnet is to be associated.

u The network address or any IP address in the range.

u The subnet mask.

Active Directory Sites and Services converts this information into the subnet address.

Requirements

u Credentials: Enterprise Admins

u Tool: Active Directory Sites and Services (Administrative Tools)

To create a subnet object

495. In Active Directory Sites and Services, expand the Sites container.

496. Right-click the Subnets container and then click New Subnet.

497. In the New Object - Subnet dialog box, in the Address box, type the network address or any IP address within the range of IP addresses for the subnet.

498. In the Mask box, type the subnet mask.

499. In the Site Name box, click the site to which this subnet is being associated, and then click OK.

Create a Temporary Connection Link for Replication Partners

Using the repadmin tool to create a temporary connection link for replication partners can fail if the KCC starts while you are performing the procedure and the corresponding connection object is not yet created. The KCC will delete any replication links for which no corresponding connection object exists. Be sure to create connection object first.

These commands can take a very long time to complete as they trigger the replication of the corresponding naming context.

All naming contexts must be replicated properly. If a replication gets preempted, run the command again until it completes successfully; otherwise you might get an "access denied" error.

Requirements

Credentials: Domain Admins

Tools: Repadmin.exe

Required information: PDC emulator role holder for the domain

To create a temporary connection link for replication partners

500. At a command prompt on the configuration NC, type the following command and press ENTER:

repadmin /add <Configuration NC> <Local domain controller FQDN> <Replication partner FQDN> /u:<domain>\administrator /pw:*

501. At a command prompt on the domain NC, type the following command and press ENTER:

repadmin /add <Domain NC> <Local domain controller FQDN> <Replication partner FQDN> /u:<domain>\administrator /pw:*

502. Verify that the replication was successful by typing the following command at a command prompt:

Repadmin /showreps

Create a Two-way Trust (MMC Method)

For the following two procedures, a member of Domain Admins in the first domain performs the first procedure and a member of Domain Admins in the second domain performs the second procedure.

To create both directions of two one-way trust relationships in the first domain

503. With the administrator of the other domain, agree on a secure channel password to be used in establishing the trust.

504. In the first domain, (noam.reskit.com in this example), log on as a member of Domain Administrators.

505. In Active Directory Domains and Trusts, expand reskit.com, and then right-click noam.reskit.com.

506. Click Properties, and then click the Trusts tab.

507. Next to the Domains trusted by this domain box, click Add.

508. In the Trusted domain box, type the trusted domain name. If you are adding a Windows 2000 domain, type the full DNS name (acquired01-int.com in this example). If the domain is running an earlier version of Windows, type the domain name (acquired01-int in this example.)

509. In the Password box, type the agreed-upon password.

510. In the Confirm password box, retype the password, and then click OK.

511. A message appears that says the trust cannot be verified. Click OK.

Note

The reason for this error is that Windows 2000 is attempting to verify the secure channel. It cannot verify the secure channel at this time because the other side of the trust is not yet created.

512. Next to the Domains that trust this domain box, click Add.

513. In the Trusting domain box, type the trusting domain name. If you are adding a Windows 2000 domain, type the full DNS name (acquired01-int.com in this example). If the domain is running an earlier version of Windows, type the domain name (acquired01-int in this example.)

514. In the Password box, type the agreed-upon password.

515. In the Confirm password box, retype the password, and then click OK.

516. A message appears asking if you want to verify the trust. Click Yes.

517. Click OK to close the Properties sheet.

Note

If the trust is successfully created in the acquired01-int.com domain, click Yes to verify the trust. If the trust is not created, clicking Yes returns an error. When the trust is created in acquired01-int.com, the trust takes effect. You do not need to verify the trust for the trust to take effect.

To create both directions of two one-way trust relationships in the second domain

518. In the first domain (acquired01-int.com in this example), log on as a member of Domain Administrators.

519. In Active Directory Domains and Trusts, right-click the full DNS name of the first domain (acquired01-int.com in this example), and then click Properties.

520. Click the Trusts tab.

521. Next to the Domains trusted by this domain box, click Add.

522. In the Trusted domain box, type the full DNS name of the second domain (noam.reskit.com in this example).

523. In the Password box, type the agreed-upon password.

524. In the Confirm password box, retype the password, and then click OK.

525. A message appears that says the trusted domain has been added and the trust verified. Click OK.

526. Next to the Domains that trust this domain box, click Add.

527. In the Trusting domain box, type the full DNS name of the second domain (noam.reskit.com in this example).

528. In the Password box, type the agreed-upon password.

529. In the Confirm password box, retype the password, and then click OK.

530. A message appears asking if you want to verify the trust. Click Yes, and then click OK.

531. Click OK to close the dialog box (acquired01-int.com in this example).

Note

If the trust has been successfully created in the noam.reskit.com domain, click Yes to verify the trust. If the trust is not created, clicking Yes returns an error. When the trust is created in noam.reskit.com, the trust takes effect. You do not need to verify the trust for the trust to take effect.

Create a Two-way Trust (Netdom.exe Method)

For the following procedure, you create both sides of the two-way trust with one command. You must have the Domain Admins passwords for both domains.

To create a two-way trust by using Netdom.exe

u Open a command prompt and type the following command:

netdom trust /d:trusteddomain trustingdomain /add /twoway

where trusteddomain is the trusted domain, and trustingdomain is the trusting domain. If the domain is Windows 2000, use the full DNS name; if it is Windows NT 4.0, use the domain name. Press ENTER.

You may also enter the administrator passwords, using Pd: for the trusted domain password and Po: for the trusting domain password; if you do not enter the passwords, you will be prompted for them.

Example:

netdom trust /d:acquired.com noam.com /add /twoway

/Ud: acquired.com\admin /Pd:xxxx

/Uo: noam.com\admin /Po:yyyy

Create the New Staging Area Folder

Use this procedure to create the new folder for FRS to use as the Staging Area.

Requirements

u Credentials: Domain Admins

u Tools: Windows Explorer

To create the new Staging Area folder

532. In Windows Explorer, navigate to the appropriate location in the console tree. In the right pane, right-click on a blank area, click New and then click Folder.

533. Enter an appropriate folder name.

Create the SYSVOL Folder Structure

Use this procedure to create the SYSVOL folder structure. The %systemroot%\SYSVOL folder is the top of the folder tree for the Windows System Volume. To properly move SYSVOL, you must move the %systemroot%\SYSVOL folder and its contents. A subfolder of %systemroot%\SYSVOL is also named sysvol. Ensure that you move the proper folder (the %systemroot%\SYSVOL folder) and not the subfolder (%systemroot%\SYSVOL\sysvol). Do not confuse the two folders.

Requirements

u Credentials: Domain Admins

u Tools: Windows Explorer

To create the SYSVOL folder structure

534. In Windows Explorer, navigate to the folder that represents your current Windows System Volume. By default this is the %systemroot%\SYSVOL folder.

535. Right-click the SYSVOL folder and click Copy.

536. In Windows Explorer, navigate to the new location you created in the console tree, right-click the new location and click Paste. You might see a dialog box stating that some files already exist and a prompt asking whether you want to continue copying the folder. At each such prompt, click No.

537. Verify that the folder structure was copied correctly. Compare the new folder structure to the original. Open a command prompt and type DIR /s to list the contents of the folders. Ensure that all folders exist. If any folders are missing at the new location (such as \scripts), then recreate them.

Delete a Lingering Object from a Global Catalog Server

To perform this procedure, you must log on locally to the global catalog server at the console or through a Terminal Services connection. The global catalog server must be running Windows 2000 Server with SP3 or later.

Requirements

u Credentials: Enterprise Admins

u Tool: Ldp.exe (Support Tools)

u Operating system: Windows 2000 Server with SP3

u Required Information:

· Object GUID of the lingering object that you want to delete.

· Object GUID of a writable domain controller in the domain of the lingering object.

To delete a lingering object from a global catalog server

538. Log on locally or open a Terminal Services connection to the global catalog server.

539. In the Run dialog box, type Ldp and then click OK.

540. On the Connection menu, click Connect.

541. In the Connect dialog box, leave the Server box empty.

542. In the Port box, type 389, and then click OK.

543. On the Connection menu, click Bind.

544. In the Bind dialog box, provide Enterprise Admins credentials. Click Domain if it is not already selected.

545. In the Domain box, type the name of the forest root domain, and then click OK.

546. On the Browse menu, click Modify.

547. In the Modify dialog box, leave the Dn box empty.

548. In the Attribute box, type RemoveLingeringObject.

549. In the Values box, type <GUID= and then append the GUID of the writable domain controller.

550. At the end of the GUID, type > : <GUID= and then append the GUID of the lingering object, followed by >. You must include a single space before and after the colon (:). The entire entry in the Values box appears similar to the following example:

<GUID=8b1ddcab-c085-4605-b132-09e8bc05ab06> : <GUID=bb1682b9-8ef8-4d85-b4c3-07482edf9a08>

551. In the Operation box, click Replace, and then click ENTER.

552. Click Run to run the request. In the details pane, the result of the request appears similar to the following:

***Call Modify...

ldap_modify_s(ld, '(null)',[1] attrs);

Modified "".

Delete a Server Object from a Site

When no child objects are visible below the server object in Active Directory Sites and Services, you can remove the server object.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

u No child objects appear below the server object in Active Directory Sites and Services

To delete a server object from a site

553. In Active Directory Sites and Services, expand the Sites container and expand the site from which you want to delete a server object.

554. Expand the Servers container and then expand the server object you want to delete.

555. If no child objects appear below the server object, right-click the server object and then click Delete.

Important

Do not delete a server object that has a child object. If an NTDS Settings or other child object appears below the server object you want to delete, either replication on the domain controller on which you are viewing the configuration container has not occurred, or the server whose server object you are removing has not been properly decommissioned. If any child object persists for longer than a normal replication cycle, escalate the problem to a supervisor.

556. Click Yes to confirm your choice.

Delete a Site Link Object

Use the following procedure to delete the site link object.

Requirements

u Credentials: Enterprise Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To delete a site link object

557. In Active Directory Sites and Services, expand the Sites container and the Inter-Site Transports container, and then click the IP container.

558. In the details pane, right-click the site link object you want to delete and then click Delete.

559. Click Yes to confirm your choice.

Delete a Site Object

Delete a site object only after you have removed all server objects from the site and have reassociated the subnets with a different site. The Servers container is deleted when you delete the site.

Requirements

u Credentials: Enterprise Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To delete a site object

560. In Active Directory Sites and Services, click the Sites container.

561. In the details pane, right-click the site you want to delete, and then click Delete.

562. Click Yes to confirm your choice.

563. In the Active Directory message box, read the information and then click Yes to delete the site and its Servers container object.

Delete a Subnet Object

If the IP addresses are no longer in use, delete the subnet object or objects with which the addresses are associated.

Requirements

u Credentials: Enterprise Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To delete a subnet object

564. In Active Directory Sites and Services, expand the Sites container and then expand the Subnets container.

565. Right-click the subnet object you want to delete, and then click Delete.

Delete an Object from a Domain

Use the following procedure to delete an object from a domain.

u Credentials: Domain Admins

u Tools: Active Directory Users and Computers (Administrative Tools)

To delete an object from a domain

566. In Active Directory Users and Computers, locate the object you want to delete.

567. Right-click the object, click Delete, and then click Yes to confirm your choice.

Determine the Database Size and Location Offline

If the domain controller is started in Directory Services Restore Mode, you can use Ntdsutil.exe to report the Ntds.dit database file and log file locations, as well as the free disk space on all local drives.

Requirements

u Domain controller is started in Directory Services Restore Mode

u Credentials: local Administrator account

u Tool: Ntdsutil.exe (system tool)

To check directory database information and free disk space offline

568. With the domain controller in Directory Services Restore Mode, open a command prompt, type ntdsutil, and then press ENTER.

569. At the ntdsutil: prompt, type files, and then press ENTER.

570. At the file maintenance: prompt, type info.

571. At the file maintenance: prompt, type quit and press ENTER. Type quit and press ENTER again to quit Ntdsutil.exe.

Determine the Database Size and Location Online

If you must manage the database file, the log files, or both, first determine the location and size of the files. By default, the database file and associated log files are stored in the %systemroot%\NTDS directory.

You can also use the Search command on the Start menu to locate the database file (Ntds.dit) or the edb*.log file for the location of the database and log files, respectively.

If you have set Garbage Collection logging to report free disk space, then event ID 1646 in the Directory Service log also reports the size of the database file (“Total allocated hard disk space (megabytes):”).

Alternatively, you can determine the size of the database file by listing the contents of the directory that contains the files.

Requirements

u Credentials: Domain Admins

u Tool: Command line: dir command

To determine the directory database size online

572. On the domain controller on which you want to manage database files, open a command prompt and change directories to the directory containing the files you want to manage.

573. Run the dir command to examine the database size. In the following example, Ntds.dit file and the log files are stored in the same directory. In the example, the files take up 58,761,216 bytes of disk space.

H:\NTDS>dir
Volume in drive H has no label.

Volume Serial Number is 003D-0E9E

Directory of H:\NTDS

01/29/2002 11:04 AM <DIR> .

01/29/2002 11:04 AM <DIR> ..

01/28/2002 03:03 PM <DIR> Drop

01/29/2002 10:29 AM 8,192 edb.chk

01/29/2002 10:29 AM 10,485,760 edb.log

01/29/2002 10:29 AM 10,485,760 edb00001.log

01/29/2002 10:29 AM 14,696,448 ntds.dit

01/28/2002 02:54 PM 10,485,760 res1.log

01/28/2002 02:54 PM 10,485,760 res2.log

7 File(s) 58,761,216 bytes

3 Dir(s) 779,284,480 bytes free

Determine the Initial Change Notification Delay on a Domain Controller

The following registry entry controls the initial change notification delay:

Replicator notify pause after modify (secs) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

The default value is 300 seconds.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe

To determine the initial change notification delay on a domain controller

574. In the Run dialog box, type regedit and then click OK.

575. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS and click the Parameters entry.

576. View the value in the Data column for Replicator notify pause after modify (secs).

577. To view the decimal value, double-click Replicator notify pause after modify (secs), and in the Base box, click Decimal.

Determine the ISTG Role Owner for a Site

To determine the current ISTG role owner for a site, view the NTDS Site Settings object properties.

Requirements

u Credentials: Domain Users

u Tools: Active Directory Sites and Services (Administrative Tools)

To determine the ISTG role owner for a site

578. In Active Directory Sites and Services, click the site object whose ISTG you want to determine.

579. In the details pane, right-click the NTDS Site Settings object, and then click Properties. The current role owner appears in the Server box under Inter-Site Topology Generator.

Determine the Tombstone Lifetime for the Forest

The tombstone lifetime is an attribute value on the Directory Service object in the configuration directory partition.

Requirements

u Credentials: Domain Users

u Tools: ADSI Edit (Windows Support Tools)

To determine the tombstone lifetime for the forest

580. In ADSI Edit, expand Configuration Container, CN=Configuration, CN=Services, and CN=Windows NT.

581. Right-click CN=Directory Service, and then click Properties.

582. In the Select a property to view box, click tombstoneLifetime.

583. Note the value in the Value(s) box. If the value is <not set>, the default value of 60 days is in effect.

Determine When Intersite Replication is Scheduled to Begin

Use the properties on the site link object to determine when intersite replication between sites is scheduled to begin.

Requirements

u Credentials: Domain Users

u Tools: Active Directory Sites and Services (Administrative Tools)

To determine when intersite replication is scheduled to begin

584. In Active Directory Sites and Services, expand the Sites container and the Inter-Site Transports container, and then click the IP container.

585. In the details pane, right-click the site link object for which you want to view the schedule, and then click Properties.

586. In the SiteLinkName Properties dialog box, click View Schedule. Note the block of days and hours during which replication is allowed (available), and then click Close.

587. In the Replicate every _____ minutes box, note the number of minutes for the intervals at which replication polling takes place during an open schedule window.

588. Click OK to close the dialog box.

Determine Whether Account Lockout Policy is Defined on a Domain

Use this procedure to view the entries for the Account Lockout Policy.

Requirements

Credentials: Domain Admins

Tools: Active Directory Users and Computers

To determine whether account lockout policy is defined on a domain

589. In Active Directory Users and Computers, right-click the domain object and then click Properties.

590. Click the Group Policy tab, and then click Default Domain Policy.

591. Click Edit, and in the Group Policy dialog box under Computer Configuration, expand Windows Settings, expand Security Settings, expand Account Policies, and then click Account Lockout Policy.

592. In the details pane, view the values under Computer Setting.

Determine Whether a Domain Controller is a DNS Server

Use the following procedure to determine whether a domain controller is a DNS server.

Requirements

u Credentials: Domain Admins

u Tools: Services (Administrative Tools)

To determine whether a domain controller is a DNS server

593. Open Services.

594. View the services in the Name column and look for DNS Server.

If DNS Server shows Started in the Status column, the domain controller is running as a DNS server.

Determine Whether a Domain Controller is a Global Catalog Server

The setting for designating the domain controller as a global catalog server is located in the properties of the NTDS Settings child object of the respective server object.

Requirements

u Credentials: Domain Users

u Tools: Active Directory Sites and Services (Administrative Tools)

To determine whether a domain controller is a global catalog server

595. In Active Directory Sites and Services, expand the Sites container, expand the site of the domain controller you want to check, expand the Servers container, and then expand the server object.

596. Right-click the NTDS Settings object and then click Properties.

597. On the General tab, if the Global Catalog box is selected, the server is designated as a global catalog server.

Determine Whether a Domain Controller is a Preferred Bridgehead Server

Preferred bridgehead servers are distinguished by a property on the server object that adds the server to the preferred bridgehead server list for the IP transport.

Requirements

u Credentials: Domain Users

u Tools: Active Directory Sites and Services (Administrative Tools)

To determine whether a domain controller is a preferred bridgehead server

598. In Active Directory Sites and Services, expand the Sites container and the site in which the server object resides.

599. Expand the Servers container to display the domain controllers currently configured for that site.

600. Right-click the server object of interest and then click Properties.

601. If IP appears in the box labeled This server is a preferred bridgehead server for the following transports, the server is a preferred bridgehead server for the IP transport.

Determine Whether a Server Object has Child Objects

When a domain controller is properly installed, its server object has a child NTDS Settings object. Other applications that are running on domain controllers can also publish child objects.

After installing Active Directory on a domain controller, verify that the server object has a child NTDS Settings object.

Prior to deleting a server object from the Servers container for a site, verify that the server object has no child objects.

Requirements

u Credentials: Domain Users

u Tools: Active Directory Sites and Services (Administrative Tools)

To determine whether a server object has child objects

602. In Active Directory Sites and Services, expand the Sites container and expand the site of the server object.

603. Expand the Servers container and then expand the server object to view any child objects.

Determine Whether a Site Has at Least One Global Catalog Server

You can use Nltest.exe to list a single domain controller in a specified site. If the test fails, it means that there are no global catalog servers in the site.

Requirements

u Credentials: Authenticated User

u Tool: Nltest.exe (Support Tools)

To determine whether a site has at least one global catalog server

604. At the command prompt, type the following command and then press ENTER:

nltest /dsgetdc:forestRootDomainName /gc /site:siteName

where forestRootDomainName is the name of the forest root domain and siteName is the name of the site.

605. The output shows either one domain controller that is a global catalog server, or the command fails. If the output shows DsGetDcName failed, then the site has no global catalog servers.

Disable Compression on a Site Link

If you do not use manually created connection objects for intersite replication between two sites, you can disable compression between the sites by modifying the options attribute on the site link object.

Requirements

u Credentials: Enterprise Admins

u Tools: ADSI Edit (Windows Support Tools)

To disable compression on a site link

606. In ADSI Edit, expand the Configuration Container icon and then expand CN=Configuration,DC=ForestRootDomainName and CN=Sites.

607. Expand the CN=Inter-Site Transports container, and then click CN=IP.

608. In the details pane, right-click the site link object whose options attribute you want to change, and then click Properties.

609. In the Select a property to view box, click options.

610. If the Value(s) box displays <not set>, in the Edit Attribute box, type 4 for the value (bit 2=1).

If the Value(s) box contains a value (as it should if you have enabled change notification), you must derive the new value by using a Boolean BITWISE-OR calculation of the existing value and the value that enables the replication change you are making. Then convert that value to an integer. Therefore, if a value is set, convert the integer value to a binary value and OR that value with the value 0100. Then convert the results back to an integer and type that value in the Edit Attribute box.

For example, if the existing decimal value is 1, that value is equal to 0001 in the binary system. The value that disables compression is 4, or 0100 in binary. The OR operation combines 0 OR 0 = 0, 0 OR 1 = 1, 1 OR 0 = 1, 1 OR 1 = 1. Therefore, the following OR calculation computes the binary value:

0001 (existing value)
0100 (value that disables compression)

0101 (adds disable compression to the existing setting)

The binary value 0101 converts to the digital value 5. For information about binary calculations and converting binary values to digital values, see Windows 2000 Server Help.

611. Click Set, and then click OK.

Disable Outbound Replication

Use this procedure to disable Active Directory replication from a domain controller. The domain controller continues to receive inbound replication.

u Credentials: Domain Admins

u Tools: Repadmin.exe (Support Tools)

To disable outbound replication on a domain controller

u At the command prompt, type the following command and then press ENTER:

repadmin /options ServerName +disable_outbound_repl

where ServerName is the name of the domain controller on which you want to disable outbound replication. The tool reports the current options (the options that were in effect prior to pressing ENTER) and the new options (all options that are now in effect).

Disable Time Service

Use the following procedure to disable the W32Time time service.

Requirements

u Credentials: Domain Admins

u Tools: Services snap-in

To disable W32Time

612. Open Administrative Tools, and select Services.

613. Right-click Windows Time, and select Properties. The Windows Time Properties dialog box appears.

614. In the Startup Type field, select Disabled from the drop-down menu.

615. Click OK. Verify that the type for the time service appears as “Disabled.”

Flush the DNS Cache

Use this procedure to purge entries from the DNS cache on the local computer.

Requirements

Credentials: Local user

Tools: Ipconfig.exe

To flush the DNS cache

u At a command prompt, type the following command and press ENTER:

ipconfig /flushdns

Enable Active Directory Diagnostic Event Logging

Use this procedure to configure diagnostic event logging for Active Directory.

Requirements

Credentials: Domain Admins

Tools: Regedit

To enable Active Directory diagnostic event logging

616. In the Run dialog box, type regedit and then click OK.

617. Navigate to the appropriate entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.

618. Configure event logging for the appropriate component:

ll. In the details pane of Registry Editor, double-click the entry that represents the type of event that you want to log. For example, Security Events.

mm. Type the logging level that you want (for example, 2) in the Value data box, and then click OK.

619. Repeat step 4 for each component that you want to log.

620. On the Registry menu, click Exit to quit Registry Editor.

Enable Change Notification on a Site Link

If you do not use manually created connection objects for intersite replication, you can implement change notification between the sites by modifying the options attribute on the site link object.

Requirements

u Credentials: Enterprise Admins

u Tools: ADSI Edit (Windows Support Tools)

To enable change notification on a site link

621. In ADSI Edit, expand the Configuration Container icon and then expand CN=Configuration,DC=ForestRootDomainName and CN=Sites.

622. Expand the CN=Inter-Site Transports container, and then click CN=IP.

623. In the details pane, right-click the site link object whose options attribute you want to change, and then click Properties.

624. In the Select a property to view box, click options.

625. If the Value(s) box displays <not set>, in the Edit Attribute box, type 1 for the value (bit 0=1).

If the Value(s) box contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation of the existing value and the value that enables the replication change you are making. Then convert that value to an integer. Therefore, if a value is set, convert the integer value to a binary value and OR that value with the value 0001. Then convert the results back to an integer and type the value in the Edit Attribute box.

For example, if the existing decimal value is 4, that value is equal to 0100 in the binary system. The value that enables change notification is 1, or 0001 in binary. The OR operation combines 0 OR 0 = 0, 0 OR 1 = 1, 1 OR 0 = 1, 1 OR 1 = 1. Therefore, the following OR calculation computes the binary value:

0100 (existing value)
0001 (value that enables change notification)

0101 (adds enable change notification to the existing setting)

The binary value 0101 converts to the digital value 5. For information about binary calculations and converting binary values to digital values, see Windows 2000 Server Help.

626. Click Set and then click OK.

Enable Secure Dynamic Updates for a DNS Zone

Use this procedure to configure a DNS zone to allow secure dynamic updates.

Requirements

u Credentials: Domain Admins or DnsAdmins

u Tools: DNS MMC snap-in

To enable secure dynamic updates

627. In the console tree of the DNS MMC snap-in, right-click the applicable zone.

628. Click Properties.

629. On the General tab, verify that the zone type is Active Directory–integrated.

Note

Secure dynamic update is supported only for Active Directory–integrated zones. If the zone type is configured differently, you must change the zone type and configure it to be Active Directory–integrated prior to securing it for DNS dynamic updates.

630. In Dynamic Updates, click secure only.

Establish Credentials to Access a Remote Computer

Use this procedure to allow a user to access a remote computer.

Requirements

u Credentials: Domain Admins

u Tools: net use

To establish credentials to access a remote computer

u At a command prompt, type the following command and press ENTER:

net use \\computer\ipc$ \user: <user name>.*.

Establish the Distinguished Name and GUID of an Object

Use the following procedure to search the global catalog to identify an object by distinguished name and GUID. Use an attribute that uniquely identifies the object.

Requirements

u Credentials: Domain Users

u Tool: Ldp.exe (Support Tools)

To establish the distinguished name and GUID of an object

631. In the Run dialog box, type Ldp and then click OK.

632. On the Connection menu, click Connect.

633. In the Server box, type the name of a global catalog server.

634. In the Port box, type 3268, and then click OK.

635. On the Connection menu, click Bind.

636. In the Bind dialog box, provide credentials for a user account in the forest. If Domain is not selected, click to select it.

637. In the Domain box, type a name of the domain of the user, and then click OK.

638. On the View menu, click Tree.

639. In the Tree View dialog box, in the BaseDN box, type the distinguished name of the forest root domain, and then click OK.

640. In the console tree, right-click the forest root domain, and then click Search.

641. In the Search dialog box, in the Filter box, replace the default filter (objectClass=*) to create a filter of the following form:

(<attribute>=<value>)

where <attribute> is the LDAP name of an attribute and <value> is the value that you know to be associated with the object that you are searching for. For example, (userPrincipalName=JaneD@contoso.com), (sAMAccountName=JaneD), or (sn=Doe) to locate the duplicate user object Jane Doe. You can use the asterisk (*) in the <value> field if you want to search all objects.

642. In the Scope box, click Subtree, and then click Options.

643. Click in the Attributes box and use the right arrow key to scroll to the end of the list.

644. Type objectGUID; (including the punctuation), and then click OK.

645. Click Run to process the query, and then click Close.

646. View the results. You must identify the displayed objects that need to be removed from the global catalog. One indication that you have found a lingering object is that the object does not exist in a writable copy of the domain.

647. If necessary, repeat steps 9 through 13 to rephrase the query, and then run it again.

When you identify an object, note its distinguished name and objectGUID value.

Use the DC= components of the distinguished name of the object to identify the domain of the object.

To more easily capture these values if you need them for a different application, select the distinguished name, right-click the selection, and then click Copy. Open a text file and paste the distinguished name. Repeat the procedure for the object GUID. When you need these values later, select and copy them from the text file.

Gather the System Volume Path Information

Before you attempt to relocate all or portions of the system volume, you must clearly understand the folder structure and the relationships between the folders and the path information that is stored in the registry and the directory itself. When folders are relocated, any associated parameters that are stored in the registry and the directory must be updated to match the new location. The folder structure contains junctions that might also require updating when folders get moved to a new location.

Maintaining the relationship between the folders, junctions, and stored parameters is important when you must relocate all or portions of SYSVOL. Failure to do so can result in files being replicated to or from the wrong location. It can also result in files failing to replicate, yet FRS will not report any errors because nothing is wrong. Due to the configuration error, FRS looks in the wrong location for the files that you want to replicate.

The folder structure used by the system volume uses a feature called a junction point. Junction points look like folders and behave like folders (in Windows Explorer you cannot distinguish them from regular folders) but they are not folders. A junction point contains a link to another folder. When a program opens it, the junction point automatically redirects the program to the folder to which the junction point is linked. The redirection is completely transparent to the user and the application.

For example if you create two folders, C:\Folder1 and C:\Folder2, and create a junction called C:\Folder3, and then link the junction back to Folder1, Windows Explorer displays three folders:

\Folder1

\Folder2

\Folder3

If you open Folder3, Windows Explorer is redirected to Folder1 and displays the content of Folder1. You receive no indication of the redirection because it is transparent to the user and to Windows Explorer. If you look at the contents of Folder1, you see that it is exactly the same as the contents displayed when you open Folder3. If you open a command prompt and list a directory, all three folders appear in the output. The first two are type <DIR> and Folder3 is type <JUNCTION>. If you list a directory of Folder3, you see the contents of Folder1.

Note

To create or update junctions, you need the Linkd.exe tool supplied with the Windows 2000 Server Resource Kit. Linkd allows you to create, delete, update, and view the links that are stored in junction points.

By default, the system volume is contained in the %systemroot%\SYSVOL folder. The tree of folders contained within this folder can be extensive depending on how your network uses FRS. When relocating folders in the system volume, ensure that you move all folders (including any hidden folders) and ensure that the relationships of the folders do not change unintentionally. When you relocate folders, you need to be concerned with the first three levels of subdirectories in order to properly update the parameters used by FRS. These levels are affected by junction points and parameter settings. These folders include:

u %systemroot%\SYSVOL

u %systemroot%\SYSVOL\Domain

u %systemroot%\SYSVOL\Domain\DO_NOT_REMOVE_Ntfrs_Preinstalled_Directory

u %systemroot%\SYSVOL\Domain\Policies

u %systemroot%\SYSVOL\Domain\Scripts

u %systemroot%\SYSVOL\Staging

u %systemroot%\SYSVOL\Staging\Domain

u %systemroot%\SYSVOL\Staging Areas

u %systemroot%\SYSVOL\Staging Areas FQDN

u %systemroot%\SYSVOL\Sysvol

u %systemroot%\SYSVOL\Sysvol FQDN

where FQDN is the fully qualified domain name of the domain that this domain controller hosts.

Note

If any of the folders do not appear in Windows Explorer, click Tools and then click Folder Options. On the View tab, select the Show hidden files and folders option button.

If you use Windows Explorer to view these folders, they appear to be typical folders. If you open a command prompt and type DIR to list these folders, you will notice two special folders are listed as <JUNCTION>. Both folders labeled FQDN are junction points. The junction in %systemroot%\SYSVOL\Sysvol links to %systemroot%\SYSVOL\Domain. The junction in %systemroot%\SYSVOL\Staging Areas is linked to %systemroot%\SYSVOL\Staging\Domain. If you change the path to the folders to which the junctions are linked, you must also update the junctions, including drive letter changes and folder changes.

Besides junction points linking to folders within the system volume tree, the registry and the directory also store references to folders. These references contain paths that you must update if you change the location of the folder. FRS uses two values that are stored in the directory. The first value, fRSRootPath, points to the location of the policies and scripts that are stored in SYSVOL. By default, this location is the %systemroot%\SYSVOL\Domain folder. The second value, fRSStagingPath, points to the location of the folders used as the Staging Area. By default this location is the %systemroot%\SYSVOL\Staging\Domain folder. The Net Logon service uses a parameter stored in the registry to identify the location of the folder that it uses to create the SYSVOL and NETLOGON share points. By default, this path is %systemroot%\SYSVOL\Sysvol. If you change the paths to these folders, you must update these values.

When relocating SYSVOL, you first move the entire folder structure to a new location, then you update all the junction points and the parameters that are stored in the registry and the directory in order to maintain the relationships between the parameters, the folders, and the junctions. Optionally, you can relocate the Staging Area and leave the rest of the System Volume at its original location. In this case, you must update the fRSStagingPath parameter in the directory and the junction point stored at %systemroot%\SYSVOL\staging areas.

Requirement:

Credentials: Domain Admins

Tools: Regedit.exe, ADSI Edit, Linkd.exe

To gather the system volume path information

Use the steps below to locate the information and record the current values in Table B.1.

If you are relocating the Staging Area, you only need to record information for rows two and five in Table B.1. All other operations require that you record information in all five rows.

To restore and rebuild SYSVOL, you must record information from the domain controller that you are repairing in rows one, two, and three. Use the junctions located on the domain controller from which you are copying from the SYSVOL folder structure to record the Current Value for rows four and five. The New Values for rows four and five are based on the domain controller that you are repairing.

Table B.1   System Volume Path Information

Parameter	Current Value	New Value
1. fRSRootPath
2. fRSStagingPath
3. Sysvol in Registry
4. Sysvol Junction
5. Staging Junction

fRSRootPath

648. In the Run dialog box, type adsiedit.msc and press ENTER.

649. Double-click Domain NC [machinename], where machinename is the name of this domain controller. Verify that the Domain NC expands to display the domain component (DC=) folder.

650. Click the domain component to display the containers and OUs in the details pane. Double-click the Domain Controllers OU to display the containers that represent the domain controllers.

651. Double-click the container that represents this domain controller (CN=computername) to display more containers.

652. Double-click the CN=NTFRS Subscriptions container.

653. Right-click the CN=Domain System Volume container and click Properties.

654. The Properties for this container opens. In the Select which properties to view list, select Mandatory.

655. In the Select a property to view list, select fRSRootPath. The current value appears in the Value(s) box.

656. Record the current value in the table above. Based on the folder structure discussed earlier and the new location, record the new path value for this parameter in Table Z.Z.

657. Click Cancel to close the dialog box.

fRSStagingPath

658. In the Run dialog box, type adsiedit.msc and press ENTER.

659. Double-click Domain NC [machinename], where machinename is the name of this domain controller. Verify that the Domain NC expands to display the domain component (DC=) folder.

660. Click the domain component to display the containers and OUs in the details pane. Double-click the Domain Controllers OU to display the containers that represent the domain controllers.

661. Double-click the container that represents this domain controller (CN=computername) to reveal more containers.

662. Double-click the CN=NTFRS Subscriptions container.

663. Right-click the CN=Domain System Volume container and click Properties.

664. The Properties for this container opens. In the Select which properties to view list, select Mandatory.

665. In the Select a property to view list, select fRSStagingPath. The current value appears in the Value(s) box.

666. Record the current value in Table Z.Z. Based on the folder structure discussed earlier and the new location, record the new path value for this parameter in Table Z.Z.

SYSVOL Parameter in the Registry

667. In the Run dialog box, type regedit and press ENTER.

668. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

669. Sysvol appears in the details pane. The current value is listed in the Data column.

670. Record the current value in Table Z.Z. Based on the folder structure discussed earlier and the new location, record the new path value for this parameter in Table Z.Z.

SYSVOL Junction

671. At a command prompt, change directory to %systemroot%\SYSVOL\Sysvol.

Note

This assumes that the System Volume is still in the default location. If it has been relocated, substitute the appropriate paths into these instructions.

672. At the command prompt, type DIR. Verify that the fully qualified domain name is listed as type <JUNCTION>.

673. At the command prompt, type linkd fqdn , where fqdn is the domain name listed in the DIR output. This displays the value stored in the junction point. Press ENTER.

674. Record the current value in Table Z.Z. Based on the folder structure discussed earlier and the new location, record the new path value for this parameter in Table Z.Z.

Staging Junction

675. At a command prompt, change directory to <%systemroot%>\SYSVOL\Staging Areas.

Note

This assumes that the Staging Area is still in the default location. If it has been relocated, substitute the appropriate paths into these instructions.

676. At the command prompt, type DIR. Verify that the fully qualified domain name is listed as type <JUNCTION>.

677. At the command prompt, type linkd fqdn , where fqdn is the domain name listed in the DIR output. This displays the value stored in the junction point. Press ENTER.

678. Record the current value in Table Z.Z. Based on the folder structure discussed earlier and the new location, record the new path value for this parameter in Table Z.Z.

Generate the Replication Topology

The KCC runs by default every 15 minutes. If you want to initiate topology regeneration immediately, you can force the KCC to run, as follows:

u To generate the intersite replication topology, run the KCC on the domain controller in the site that holds the ISTG role.

u To generate the intrasite replication topology, run the KCC on any domain controller in the site that does not hold the ISTG role.

Requirements

u Credentials: Enterprise Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

u Identity of the ISTG role holder in the site

To generate the replication topology

679. In Active Directory Sites and Services, expand the Sites container and expand the site that contains the server on which you want to run the KCC.

680. Click the Servers container, and then click a server object.

681. Expand the server object to display the NTDS Settings object.

682. Right-click the NTDS Settings object, click All Tasks, and then click Check Replication Topology.

683. In the Check Replication Topology message box, click OK.

Identify a Revived Lingering Object and Replication Source on a Writable Domain Controller

Event ID 1388 in the Directory Service event log identifies the lingering object and its domain controller source location. Use the information in the following procedure to interpret the event text, identify the lingering object, and trace the error to its source.

Requirements

u Credentials: Domain Admins

u Tools:

· Event Viewer (Administrative Tools)

· Repadmin.exe (Support Tools)

To identify a revived lingering object and replication source on a writable domain controller

684. In Event Viewer, locate event ID 1388 and make a note of the object name, which is the name of the revived lingering object. The following example of this error identifies the user object named User1 in the Users container in the domain child.forestRoot.com:

This destination system received an update for object which should have been present locally, but was not. The attribute set included in the packet is not sufficient to create the object. A full copy of the object will be requested.

Object Name: CN=user1,CN=Users,DC=child,DC=forestRoot,DC=com Object GUID: 18f811af-f073-4c7d-82c6-535b5e671f11 Partition: DC=child,DC=forestRoot,DC=com Transport-specific source address: 4ce3818d-4cbb-489b-8380-6789b3d5304f._msdcs.forestRoot.com Destination highest property update USN: 4509

685. In the event ID 1388 message, note the GUID of the domain controller that is identified in “Transport-specific source address:” This domain controller is the source for the described inbound replication (the domain controller that replicated the lingering object identified in the error). The preceding example of this error identifies the domain controller by GUID 4ce3818d-4cbb-489b-8380-6789b3d5304f.

Note

The event text also includes the GUID of the object. Make sure to use the GUID that is identified in “Transport-specific source address.”

686. Open a command prompt and type the following command, and then press ENTER:

repadmin /showreps ServerName /u:DomainName\UserName /pw:*

where:

· ServerName is the name of the domain controller that received event ID 1388 (the destination domain controller).

· DomainName is the domain of the destination domain controller.

· UserName is the name of an administrative account in that domain.

If you are logged on as an administrator in the domain of the destination domain controller, omit the /u: and /pw: switches.

687. When prompted, type the password for the user account you provided, and then press ENTER.

688. Compare the GUID in the event log message to the GUID of the inbound neighbor that replicated the domain directory partition. The following example shows the output from repadmin /showreps on the domain controller that received the error in step 1. The entry for replication of the domain DC=child,DC=forestRoot,DC=com shows the name of the source domain controller from which the destination domain controller (child-dc-01) received the lingering object in the domain child.forestRoot.com. In the example, the source (inbound neighbor) domain controller name is child-dc-02. The GUID in the output matches the GUID in the text of event ID 1388.

C:\>repadmin /showreps child-dc-01 /u:child\adminUser /pw:*

Password:

BOSTON\CHILD-DC-01

DSA Options : (none)

objectGuid : 8b1ddcab-c085-4605-b132-09e8bc05ab06

invocationID: 9a7afb04-43c6-45d7-aa3d-7fd8277326fb

==== INBOUND NEIGHBORS ======================================

DC=child,DC=forestRoot,DC=com

BOSTON\CHILD-DC-02 via RPC

objectGuid: 4ce3818d-4cbb-489b-8380-6789b3d5304f

Last attempt @ 2002-05-20 12:49.20 was successful.

689. In Event Viewer, connect to the domain controller you identified in step 5 and check the Directory Service log for the presence of event ID 1388. In the details pane, click Event to order the event numbers for easier viewing.

690. Repeat steps 2 through 6 until you identify a source domain controller that does not have event ID 1388. This domain controller is the outdated domain controller. Make a note of the distinguished name of this domain controller.

Identify and Delete a Known Non-Replicated Lingering Object on an Outdated Domain Controller

On domain controllers that are running Windows 2000 Server with SP3 and that have strict replication consistency enforced, replication of lingering objects is blocked by the destination domain controller. By viewing the error, you can identify the object and the source domain controller, and then delete the error from the source (outdated) domain controller.

Requirements

u Credentials: Domain Admins

u Tools:

· Event Viewer (Administrative Tools)

· Active Directory Users and Computers

To identify and delete a known non-replicated lingering object on an outdated domain controller

691. In Event Viewer, locate occurrences of event ID 1084. The error identifies the object that could not be replicated and the source domain controller.

692. In Active Directory Users and Computers, locate the object in the appropriate container or organizational unit, according to the distinguished name of the object in the error.

693. Right-click the object and then click Delete.

Identify Replication Partners

Use this procedure to examine the connection objects for a domain controller and determine its replication partners.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Sites and Services

To identify replication partners

694. In Active Directory Sites and Services, expand the Sites container to display the list of sites.

695. Double-click the site that contains your domain controller.

Note

If you do not know the site that contains your domain controller, open a command prompt and type ipconfig to get the IP address of the domain controller. Use the IP address to verify that an IP address maps to a subnet and determine the site association.

696. Expand the Servers folder to display the list of servers in that site.

697. Expand the name of your domain controller to display its NTDS Settings.

698. Double-click NTDSSettings to display the list of connection objects in the details pane (these represent inbound connections used for replication). The From Server column displays the names of the domain controllers that are the replication partners.

Identify the GUID of a Domain Controller

The object GUID of a domain controller is stored in the objectGUID attribute of the NTDS Settings object. Use Repadmin.exe to list the value of the GUID for a domain controller.

Requirements

u Credentials: Domain Admins

u Tool: Repadmin.exe (Support Tools)

To identify the GUID of a domain controller

699. At a command prompt, type the following command and then press ENTER:

repadmin /showreps ServerName

where ServerName is the name of the domain controller for which you want to display the GUID.

700. In the first section of the output, locate the objectGuid entry. Select and copy the GUID value into a text file if you need to use it elsewhere.

Identify Unknown Lingering Objects on an Outdated Domain Controller

After identifying an outdated domain controller, you can identify any other lingering objects that it might contain. In this procedure, list the contents of Active Directory on the outdated domain controller and a replication partner to accomplish the following:

u Compare the objects in the database replicas to identify inconsistencies.

u If an object class has an inconsistent number of objects on each domain controller, filter for that class on the outdated domain controller and identify the names of the object or objects that exist on the outdated domain controller but not on its replication partner.

Identify the replication partner as follows:

u If domain controllers are running Windows 2000 Server with SP2, use the error message in event ID 1388 to trace the error to the first destination to receive the outdated replication, and use this domain controller as the replication partner.

u If domain controllers are running Windows 2000 Server with SP3, use the domain controller that generated event ID 1084 as the replication partner.

Requirements

u Credentials: Domain Admins

u Tools: Dsastat.exe (Support Tools)

To identify unknown lingering objects on an outdated domain controller

701. Open a command prompt and type the following command, and then press ENTER:

Dsastat /s:OutdatedServerName;PartnerServerName

where:

· OutdatedServerName is the name of the domain controller that has lingering objects.

· PartnerServerName is the name of the replication partner that has received replication from the outdated server.

This process can be time-consuming, depending on how many objects must be compared. When the comparison process is complete, the output indicates success or failure.

702. If the command fails with the error “Different Directory Information Trees,” scroll to the portion of the output labeled
=>> | *** DSA Diagnostics ***|<<=

The output shows a column of LDAP class names and two columns of numbers, one for each server. The numbers indicate how many instances of the class exist on each domain controller.

Note

If the command reports “Identical Directory Information Trees,” no lingering objects are present on OutdatedServerName.

703. Under Objects per server, scan the list to locate object classes that have numbers that are not identical in both server columns. Note the class names.

704. At the command prompt, type the following command, and then press ENTER:

Dsastat /s:OutdatedServerName;PartnerServerName
-filter:(objectclass=LDAPClassName) -t:false

where LDAPClassName is the name of a class that you identified in step 3. You must include a space between PartnerServerName and -filter and between the filter and -t:false.

705. When the command completes, scroll to the portion of the output labeled Checking for missing replies. Make a note of the distinguished names in the list. These are the names of the objects that appear on the outdated domain controller but not on the partner.

Note

To facilitate recording the distinguished names, open Notepad and then select, copy, and paste the appropriate text into Notepad.

For example, the following output indicates that a user named User2 exists on the outdated server, whose user class showed a number that was 1 object higher than the partner server.

Checking for missing replies...

Fail [2]: missing 1 replies for '<GUID=cf0972be031bec4d8420d70ff071cbfc>;<SID=0105000000000005150000001199b9789a7cd636dbeb0c5052040000>;CN=user2,CN=Users,DC=child,DC=ForestRoot,DC=com'

INFO: Server sizes are not equal (min=4453, max=4726).

*** Different Directory Information Trees. 2 errors (see above). ***

FAIL -=>> FAIL <<=-

closing connections...

3chw2k; 4chw2k;

706. Repeat steps 4 and 5 for each class of object that does not match between the two servers.

Import the SYSVOL Folder Structure

Use this procedure to copy the SYSVOL folder structure from another domain controller. The %systemroot%\SYSVOL folder is the top of the folder tree for the Windows System Volume. To properly import SYSVOL, you must copy the %systemroot%\SYSVOL folder and its contents.

To use this procedure, the default shared folder Admin$ must exist on the domain controller from which you plan to copy the SYSVOL folder structure. Some organizations remove this shared folder or rename it for security reasons. If this shared folder is not available, you must share the %systemroot% folder and name the share point Admin$. If you share the %systemroot% folder in order to complete this procedure, ensure that you remove the share point after the procedure is complete to maintain any security policies established on your network. If the Admin$ share has been renamed, then use the name assigned by your organization instead of Admin$ while completing this procedure.

WARNING

Never copy information from the System Volume on one domain controller to the System Volume on another domain controller unless you have stopped the File Replication service and configured SYSVOL for a non-authoritative restore during startup. Failure to do so can cause invalid data to be replicated and cause the System Volumes on various domain controllers to become inconsistent.

Requirements

u Credentials: Domain Admins

u Tools: Windows Explorer, Linkd.exe

To import the SYSVOL folder structure

707. Use Windows Explorer to delete the existing %systemroot%\SYSVOL folder that you are rebuilding.

708. Connect to the Admin$ share on the domain controller that you identified earlier as the replication partner from which you plan to copy the SYSVOL folder structure.

709. Once you are connected to the Admin$ share point, verify that a folder labeled SYSVOL appears. Right-click the SYSVOL folder and click Copy.

710. In the same directory find some blank space and right-click. Click Paste. You might see a dialog box stating that some files already exist and a prompt asking whether you want to continue copying the folder. At each such prompt, click No.

711. Verify that the original SYSVOL folder and a new folder labeled Copy of SYSVOL both appear. Right-click on Copy of SYSVOL and click Rename. Type SYSVOL2 and press ENTER.

712. Open a command prompt. Change to the drive letter that represents the connection to the remote domain controller where you created the SYSVOL2 folder.

713. Change directory to SYSVOL2\sysvol.

714. Type DIR and press ENTER. Verify that <JUNCTION> appears in the DIR output and is followed by the name of the domain.

715. You must update the path in this junction so that it points to the new location. Type the following command:

linkd junctionname newpath

where newpath is the New Value you recorded in row four of Table B.1 while gathering the system volume path information. Press ENTER

716. If the Staging Area has been relocated and is no longer inside the SYSVOL folder, skip steps 10 and 11 and proceed to step 12. At a command prompt, change directory to \SYSVOL2\staging areas under the copy of SYSVOL that you created. Type DIR to list the contents and verify that <JUNCTION> appears in the DIR output.

717. Update the junction so that it points to the new location. Type the following command:

linkd junctionname newpath

where newpath is the New Value that you recorded in row five of Table B.1 while gathering system volume path information. Press ENTER.

718. At the command prompt, change back to the %systemroot% for the domain controller that you are repairing.

719. From the command prompt, use Xcopy to copy the contents of the \SYSVOL2 folder you created to a new SYSVOL folder on your local drive. Type the following command:

xcopy drive:\sysvol2\*.* sysvol\*.* /s /e /h /c /y

where drive is the letter representing the connection to the remote domain controller. Press ENTER.

720. Verify that the folder structure copied correctly. Compare the new folder structure to the SYSVOL (not the SYSVOL2) on the remote domain controller. Open a command prompt and use DIR to list the contents of the folders. Ensure that all folders exist.

721. Remove the SYSVOL2 folder that you created on the remote domain controller.

722. Disconnect from the remote domain controller. If you had to create a shared folder on that domain controller in order to connect to it, remove the shared folder. Some organizations consider it a security risk to retain shared folders that are not in use.

723. Restart the domain controller in normal mode.

Install Active Directory

After you gather information as described in “Gathering Installation Information” earlier in this guide, you can use the Active Directory Installation Wizard to install Active Directory..

Requirements

u Credentials: local Administrator

u Tools: Dcpromo.exe

To install Active Directory

724. In the Run dialog box, type dcpromo and click OK.

725. The Active Directory Installation Wizard appears. Click Next at the Welcome screen.

726. For Domain Controller Type, select Additional domain controller for an existing domain. Click Next.

727. For Network Credentials, enter the user name, password, and domain for the user account that has permission to add this new domain controller to the domain. Click Next.

728. Enter the name of the domain that you want the new domain controller to host. Click Next.

729. For the Database and Log Locations, enter the paths for the locations of the directory database (Ntds.dit) and the log files. For better performance, store the database and log files on separate physical disk drives. Click Next.

730. For the Shared System Volume, enter the path where you want to locate the system volume (SYSVOL). Click Next.

731. Under Directory Services Restore Mode Administrator Password, enter the password that you want to use when you need to start Directory Services Restore Mode. Click Next.

732. The Summary screen displays a list of the items you chose. Verify that the information is correct and then click Next to proceed with the installation.

733. The wizard proceeds to install Active Directory. When it finishes, the wizard displays a summary screen listing the domain and site in which the new domain controller is a member. Note this information and ensure that it is correct. If the domain controller is not in the correct site, see “Performing Active Directory Post-Installation Tasks” earlier in this guide. Click Finish to close the wizard.

734. Click Restart to restart the domain controller.

735. Let the domain controller restart. If any message indicates that one or more services has failed to start, restart the domain controller one more time. If the initial replication cycles have not had enough time to complete during the first restart on a new domain controller, this can result in some services being unable to start successfully. If the message appears during additional restarts, examine the event logs in Event Viewer to determine the cause of the problem.

Install the DNS Server Service

Assign a static IP address, rather than a dynamically-assigned IP address, to any computer that acts as a DNS server. To use this procedure, your DNS infrastructure must already exist, function properly, and be configured to use Active Directory-integrated zones. This procedure describes the steps to add an additional DNS server into the DNS infrastructure.

Requirements

u Credentials: Domain Admin or Enterprise Admin

u Tools: My Network Places, Control Panel

To install the DNS Server service

736. Ensure that the computer is using a static IP address. Right-click My Network Places and click Properties.

737. In the Network and Dial-up Connections dialog box, right-click the connection that represents the connection this computer uses to attach to your network. The default label is Local Area Connection but this can be changed so it might not be labeled the same on your computer. Click Properties.

738. In the Local Area Connection Properties dialog box, click once on the Internet Protocol (TCP/IP) to highlight it (ensure that you do not clear the check box in front of it), and then click Properties.

739. In the Internet Protocol (TCP/IP) Properties dialog box, ensure that Use the following IP address: is selected and that a valid IP address, subnet mask and default gateway appears. Click OK to close the dialog box. Click OK again to return to your desktop.

740. In Control Panel, click Add/Remove Programs. Click Add/Remove Windows Components.

741. Scroll down to Networking Services. Highlight it and click Details.

742. In the Networking Services dialog box, select the check box in front of Domain Name System (DNS). Click OK.

743. Click Next. Provide the location of the installation files if necessary. After the installation is complete, click Finish to end the wizard then click Close to exit Add/Remove Programs.

Locally Restart a Domain Controller in Directory Services Restore Mode

To take a domain controller offline, restart it in Directory Services Restore Mode and log on as the local Administrator. If you have physical access to the domain controller, you can start in Directory Services Restore Mode locally.

In Directory Services Restore Mode, the domain controller is running as a member server and not a domain controller. When you start Windows 2000 Server in this mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires using the local Administrator password, not an Active Directory domain password.

Requirements

u Credentials: local Administrator account

u Tool: N/A

To locally restart in Directory Services Restore Mode

744. Restart the domain controller.

745. When the screen for selecting an operating system appears, press F8.

746. Select Directory Services Restore Mode from the Windows Advanced Options menu.

747. When prompted, log on as the local Administrator.

Monitor Global Catalog Removal in Event Viewer

The KCC logs an event that indicates that the global catalog has been removed from a domain controller.

Requirements

u Credentials: Domain Users

u Tools: Active Directory Sites and Services (Administrative Tools)

To monitor global catalog removal in Event Viewer

748. Click Start, point to Programs, point to Administrative Tools, and then click Event Viewer.

749. Right-click Event Viewer (Local), and then click Connect to another computer.

750. In the Select Computer dialog box, click Another computer, type the name of the server from which you removed the global catalog, and then click OK.

751. Under Event Viewer, click the Directory Service log.

752. Look for NTDS KCC event ID 1268, which indicates that the global catalog is removed from the local machine.

Monitor Global Catalog Replication Progress

To see the percentage of completeness of the replication of partial read-only directory partitions to a new global catalog server, monitor the replication progress.

Requirements

u Credentials: Domain Admins

u Tools: Dcdiag.exe (Support Tools)

To monitor replication progress on a new global catalog server

753. At the command prompt, type the following command and then press ENTER:

dcdiag /v /s:servername | find “%”

where servername is the name of the new global catalog server

754. Repeat this command periodically to monitor progress. If the test shows no output, then replication has completed.

Move a Server Object to a Different Site

Moving a server object requires that the IP address of the domain controller maps to the site to which you are moving the server object. After you have verified that the IP address maps to the target site, use the following procedure to move the server object to the site.

Requirements

u Credentials: Enterprise Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To move a server object to a different site

755. In Active Directory Sites and Services, expand the Sites container and the site in which the server object resides.

756. Expand the Servers container to display the domain controllers that are currently configured for that site.

757. Right-click the server object you want to move and then click Move.

758. In the Site Name box, click the destination site and then click OK.

759. Expand the site object to which you moved the server and then expand the Servers container.

760. Verify that an object for the server you moved exists.

761. Expand the server object and verify that an NTDS Settings object exists.

Within an hour, the Net Logon service on the domain controller registers the new site information in DNS. Wait an hour and then open Event Viewer and connect to the domain controller whose server object you moved. Review the Directory Service log for Net Logon errors regarding registration of SRV resource records in DNS that have occurred within the last hour. The absence of errors indicates that Net Logon has updated DNS with site-specific SRV resource records. Net Logon event ID 5774 indicates that the registration of DNS resource records has failed. If this error occurs, contact a supervisor and pursue DNS troubleshooting.

Move the Directory Database Files to a Local Drive

To move the directory database files to a different local directory, always use Ntdsutil.exe because this tool automatically updates the registry with the new path.

If you need to reformat the partition that currently stores the database file, the log files, or both, then you must move the files temporarily while you reformat the original drive. After you reformat the drive, use the same procedure to move the files back. Even if you are moving the files only temporarily, use Ntdsutil.exe so that the registry is always current.

Note

If the SYSVOL folder is stored on the partition you are reformatting, you must move SYSVOL as well as the database files, which requires a separate procedure. If SYSVOL is stored on the partition you are reformatting and you do not have instructions for moving SYSVOL, contact a supervisor.

The registry entries that Ntdsutil.exe updates when you move the database file are as follows:

In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters:

u Database backup path

u DSA Database file

u DSA Working Directory

The registry entry that Ntdsutil.exe updates when you move the log files is as follows:

In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters:

u Database log files path

Requirements

u Domain controller is started in Directory Services Restore Mode

u Credentials: local Administrator account

u Disk space:

· Temporary location: Free space on the destination drive equivalent to at least the current size of the database file, the combined log files, or both, depending on what files you are moving.

· Permanent location: Free space on the destination NTFS drive equivalent to at least the size specified below, plus space to accommodate anticipated growth, depending on what file or files you are moving:

Caution

The drive that is the permanent location of the database file or log files must be formatted as NTFS.

Database file only: The size of the database file plus 20 percent of the Ntds.dit file or 500 MB, whichever is greater.

Log files only: The size of the combined log files plus 20 percent of the combined logs or 500 MB, whichever is greater.

Database and logs. If the database and log files are stored on the same partition, free space should be at least 20 percent of the combined Ntds.dit and log files, or 1 GB, whichever is greater.

Important

The preceding levels are minimum recommended levels. If you have followed the recommendations in “Monitoring Active Directory” in this guide, falling below these minimum levels causes a monitoring warning. Therefore, adding additional space according to anticipated growth is recommended.

u Tools:

· Command line: dir command

· Ntdsutil.exe (system tool)

· Windows Explorer

To move the directory database files to a different local drive

762. In Directory Services Restore Mode, open a command prompt and change directories to the current location of the directory database file (Ntds.dit) or the log files, whichever you are moving.

763. Run the dir command and make a note of the current size and location of the Ntds.dit file.

764. At the command prompt, type ntdsutil and then press ENTER.

765. At the ntdsutil: prompt, type files and then press ENTER.

766. To move the database file, at the file maintenance: prompt, use the following commands:

· To move the Ntds.dit file, type:

move db to drive:\directory

where drive:\directory is the path to the new location. If the directory does not exist, then Ntdsutil.exe creates it.

Note

If the directory path contains any spaces, the entire path must be surrounded by quotation marks (for example, move DB to "g:\new folder").

· To move the log files, type:

move logs to drive:\directory

767. After the move completes, at the file maintenance: prompt, type quit and press ENTER. Type quit and press ENTER again to quit Ntdsutil.exe.

768. Change to the destination directory and then run the dir command to confirm the presence of the files. If you have moved the database file, then check the size of the Ntds.dit file against the file size you noted in step 2 to be sure that you are focused on the correct file.

769. If you are moving the database file or log files permanently, go to step 9.

If you are moving the database file or log files temporarily, you can now perform any required updates to the original drive. After you update the drive, repeat steps 1 through 7 to move the files back to the original location.

770. If the path to the database file or log files has not changed, go to step 10.

If the path to the database file or log files has changed from the original location, check permissions on the database folder or logs folder while still in Directory Services Restore Mode, as follows:

nn. In Windows Explorer, right-click the folder to which you have moved the database file or log files, and then click Properties.

b. Click the Security tab and verify that the permissions are:

· Administrators group has Allow Full Control.

· SYSTEM has Allow Full Control.

· Inheritable permissions are not allowed (checkbox is cleared).

· No Deny permissions are selected.

c. If the permissions in step 9b are in effect, then go to step 10. If permissions other than those described in step 9b are in effect, then perform steps 9d through 9k.

d. If Allow inheritable permissions from parent to propagate to this object is selected, click to clear it.

e. When prompted, click Copy to copy previously inherited permissions to this object.

f. If Administrators or SYSTEM, or both, are not in the Name list, click Add.

g. On the Select Users or Groups page, in the Look in: box, be sure the name of the local computer is selected.

h. In the Name list, click SYSTEM if needed, and then click Add. Repeat to add Administrators, if needed, and then click OK.

i. On the Security tab, click SYSTEM and then in the Allow column, click Full Control. Repeat for Administrators.

j. In the Name box, click any name that is not SYSTEM or Administrators, and then click Remove. Repeat until the only remaining accounts are Administrators and SYSTEM, and then click OK.

Note

Some accounts might appear in the form of SIDs. Remove any such accounts.

k. Click OK to close Properties.

771. At the command prompt, type ntdsutil and then press ENTER.

772. At the ntdsutil: prompt, type files and then press ENTER.

773. At the file maintenance: prompt, type integrity and then press ENTER.

If the integrity check fails, perform semantic database analysis with fixup.

774. If the integrity check succeeds, type quit and press ENTER to quit the file maintenance: prompt. Type quit and press ENTER again to quit Ntdsutil.exe.

775. Restart the domain controller normally. If you are performing this procedure remotely over a Terminal Services connection, be sure that you have modified the Boot.ini file for normal restarting before you restart the domain controller.

If errors appear when you restart the domain controller:

776. Restart the domain controller in Directory Services Restore Mode.

777. Check the errors in Event Viewer.

If the following events are logged in Event Viewer on restarting the domain controller, address the events as follows:

· 1046: “The Active Directory database engine caused an exception with the following parameters.” In this case, Active Directory cannot recover from this error and you must restore from backup media.

· 1168: “Internal error: An Active Directory error has occurred.” In this case, information is missing from the registry and you must restore from backup media.

Perform Authoritative Restore of a Subtree or Leaf Object

This step marks the subtree or leaf object you restored as authoritative for the directory.

Requirements

u Credentials: local Administrator

u Tool: Ntdsutil.exe

To perform authoritative restore of a subtree or leaf object

778. Open a command prompt and type ntdsutil and then press ENTER.

779. At the ntdsutil: prompt, type authoritative restore and then press ENTER.

780. At the ntdsutil authoritative restore: prompt, type:

Restore Subtree OU=ouname,DC=domain,DC=domainroot

For example, if the administrator has inadvertently deleted the Marketing organizational unit in the domain called contoso.com, type:

Restore Subtree OU=Marketing,DC=Contoso,DC=COM

781. At the Authoritative Restore Confirmation dialog box, click OK.

782. Type quit and press ENTER until you have exited Ntdsutil.exe.

783. Restart the server.

Perform Authoritative Restore of Entire Directory

This step restores the entire Active Directory, and marks it as authoritative for the enterprise.

Requirements

u Credentials: local Administrator

u Tool: Ntdsutil.exe

To perform authoritative restore of the entire directory

784. Open a command prompt and type ntdsutil and then press ENTER.

785. At the ntdsutil: prompt, type authoritative restore and then press ENTER.

786. At the ntdsutil authoritative restore: prompt, type restore database and press ENTER.

787. At the Authoritative Restore Confirmation dialog box, click OK.

788. Type quit and press ENTER until you have exited Ntdsutil.exe.

789. Restart the server. It is now authoritative for the domain, and changes will be replicated to the other domain controllers in the enterprise.

Perform Directory Database Recovery

Use the following procedure to recover the Active Directory database when errors are reported by Ntdsutil.exe during semantic database analysis with fixup.

WARNING

Do not confuse the Recover command with the Repair command. Never use the Repair command in Ntdsutil.exe. Forest-wide data loss can occur.

Requirements

u Domain controller is started in Directory Services Restore Mode

u Run this command only if errors are reported by Ntdsutil.exe during fixup (go fixup) semantic database analysis.

u Credentials: local Administrator account

u Tool: Ntdsutil.exe (system tool)

To perform directory database recovery

790. If you are not already at the ntdsutil: prompt, open a command prompt, type ntdsutil, and then press ENTER.

791. At the ntdsutil: prompt, type files and then press ENTER.

792. At the file maintenance: prompt, type recover and then press ENTER.

· If recovery does not perform successfully, either restore the domain controller from backup or rebuild the domain controller.

· If directory database recovery succeeds, type quit and then type quit again to close Ntdsutil.exe, and then restart the domain controller normally. If you are performing this procedure remotely over a Terminal Services connection, be sure that you have modified the Boot.ini file for normal restarting before you restart the domain controller.

Perform Semantic Database Analysis with Fixup

When you run Semantic database analysis with the Go Fixup command instead of the Go command, errors are written into dsdit.dmp.xx log files. A progress indicator reports the status of the check.

Requirements

u Domain controller is started in Directory Services Restore Mode

u Credentials: local Administrator account

u Tool: Ntdsutil.exe (system tool)

To perform semantic database analysis with fixup

793. If you are not already at the ntdsutil: prompt, open a command prompt, type ntdsutil, and then press ENTER.

794. At the ntdsutil: prompt, type semantic database analysis and then press ENTER.

795. At the semantic checker: prompt, type verbose on and then press ENTER.

796. At the semantic checker: prompt, type go fixup and then press ENTER.

· If errors are reported during the semantic database analysis Go Fixup phase, perform directory database recovery.

WARNING

Do not confuse the Recover command with the Repair command. Never use the Repair command in Ntdsutil.exe. Forest-wide data loss can occur.

· If semantic database analysis with fixup succeeds, type quit and then type quit again to close Ntdsutil.exe, and then restart the domain controller normally. If you are performing this procedure remotely over a Terminal Services connection, be sure that you have modified the Boot.ini file for normal restarting before you restart the domain controller.

Prepare a Domain Controller for Non-Authoritative SYSVOL Restore

Initiate a non-authoritative restore of SYSVOL by modifying the value of the BurFlags (backup/restore flags) registry entry. Changing the value to D2 (hexadecimal) or 210 (decimal) prior to disconnecting a domain controller initiates an automatic non-authoritative restore of SYSVOL when the domain controller is restarted.

Separate entries exist for global and replica-set-specific BurFlags, as follows:

u To initiate a non-authoritative restore of SYSVOL when it is the only replica set that is represented on the domain controller, set the value of the global BurFlags (REG_DWORD) entry under

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

u If other replica sets are represented on the domain controller and you want to restore only SYSVOL, set the value of the replica-set-specific BurFlags (REG_DWORD) entry under

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\SYSVOL GUID

Modifying the replica-set-specific BurFlags entry requires identifying the SYSVOL GUID in the registry.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe

To prepare a domain controller for non-authoritative SYSVOL restore

797. In the Run dialog box, type regedit and then click OK.

798. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters

799. Expand Parameters.

800. Modify one of the BurFlags entries as follows:

To modify the global BurFlags entry:

· Expand Backup/Restore and then click Process at Startup.

To modify the replica-set-specific BurFlags entry:

· Expand both Cumulative Replica Sets and Replica Sets.

· Match the GUID under Replica Sets to the identical GUID under Cumulative Replica Sets, and click the matching GUID under Cumulative Replica Sets.

801. In the details pane, double-click BurFlags.

802. In the Value data box, type D2 hexadecimal or 210 decimal, and then click OK.

Purge the Ticket Cache

Use this procedure to purge the Kerberos ticket cache.

Requirements

Credentials: Domain Admins

Tools: Kerberos List (Klist.exe), a Resource Kit tool.

To purge the ticket cache

803. At a command prompt, type the following command and press ENTER:

klist purge

804. Answer Yes for each ticket

Remotely Restart a Domain Controller in Directory Services Restore Mode

To take a domain controller offline, restart it in Directory Services Restore Mode and log on as the local Administrator. If the administrative computer has Terminal Services Client installed and the domain controller has Terminal Services installed and configured in Remote administration mode, you can connect to the domain controller, modify the boot.ini file, and restart the domain controller in Directory Services Restore Mode.

In Directory Services Restore Mode, the domain controller is running as a member server and not a domain controller. When you start Windows 2000 Server in this mode, the local Administrator account is authenticated by the local SAM database. Therefore, logging on requires using the local Administrator password, not an Active Directory domain password.

Requirements

u Credentials: local Administrator account

u Tools: Terminal Services Client, Notepad

To remotely restart in Directory Services Restore Mode

805. On a Terminal Services client, connect to the domain controller you want to restart in Directory Services Restore Mode. Perform the following steps on the remote domain controller.

806. When connected, open a command prompt and change to the system directory.

807. At the command prompt, type the following and then press ENTER:

Attrib -r -s -h boot.ini

808. To open the boot.ini file, type the following and then press ENTER:

Notepad boot.ini

809. Modify the default entry to include the /SAFEBOOT:DSREPAIR switch, as shown in the following example:

multi(0)disk(0)rdisk(0)partition(2)\WINNT="W2K DC \\<your server name>" /fastdetect /SAFEBOOT:DSREPAIR

Note

The /SAFEBOOT:DSREPAIR switch works for domain controllers running Windows 2000 Server family.

810. Save the modified boot.ini file and close Notepad.

811. On the Start menu, click Shut Down and then click Restart. During the restart process, the Terminal Services Client reports the session is disconnected.

Caution

Be sure to click Restart and not Shut Down at this step. If you click Shut Down, you cannot remotely restart the domain controller.

812. Wait for a period adequate for the restart process to complete on the remote domain controller, and then reconnect the client session.

813. When reconnected, log on as the local Administrator.

814. Before continuing with offline procedures, open a command prompt and change to the system directory.

815. At the command prompt, type the following and then press ENTER:

Notepad boot.ini

816. Delete the /SAFEBOOT:DSREPAIR switch from the default entry in the boot.ini file and save the file. Close Notepad.

Important

If you restart the domain controller before you modify the boot.ini file, the domain controller remains offline.

817. At the command prompt (still in the system directory), type the following and then press ENTER:

Attrib +r +s +h boot.ini

The boot.ini file is now returned to its original state, which starts the domain controller normally.

Remove a Manually Configured Time Source on a Selected Computer

Use the following procedure to remove a manually configured time source on a selected computer.

Requirements

u Credentials: Domain Admins

u Tools: net time

To remove a manually configured time source on a selected computer

818. At the command prompt, type the following command and then press ENTER:

net time /setsntp

819. To verify that the manually configured time source has been cleared, at the command prompt type the following command and then press ENTER:

net time /querysntp

Verify that you receive the following message: “This computer is not currently configured to use a specific SNTP server.”

Remove a Manually Created Trust

You can remove a manually created trust by using Active Directory Domains and Trusts or by using Netdom.exe.

To remove a trust by using Active Directory Domains and Trusts

820. Log on to the first domain.

821. In Active Directory Domains and Trusts, in the console tree, right-click one of the domain nodes involved in the trust you want to remove, and then click Properties.

822. Click the Trusts tab.

823. In either Domains trusted by this domain or Domains that trust this domain, click the trust to be removed, and then click Remove.

824. Repeat this procedure for the other domain involved in the trust.

To remove a trust by using Netdom.exe

To remove a trust using Netdom.exe, use one of the following procedures, depending on whether the trust is one-way or two-way.

u To remove a one-way trust, open a command prompt and type the following command, and then press ENTER:

netdom trust /d:trusteddomain trustingdomain /remove

where trusteddomain is the trusted domain, and trustingdomain is the trusting domain. If the domain is Windows 2000, use the full DNS name; if it is Windows NT 4.0, use the domain name. You will be prompted for the administrator password.

‑Or‑

u To remove a two-way trust, open a command prompt and type the following command, and then press ENTER:

netdom trust /d:trusteddomain trustingdomain /remove /twoway

where trusteddomain is the trusted domain, and trustingdomain is the trusting domain. If the domain is running Windows 2000, use the full DNS name; if it is running Windows NT 4.0, use the domain name. You must have credentials for both domains. You will be prompted for both passwords.

Remove a Site from a Site Link

Use site link properties to remove a site from a site link.

Requirements

u Credentials: Enterprise Admins

u Tool: Active Directory Sites and Services (Administrative Tools)

To remove a site from a site link

825. In Active Directory Sites and Services, expand the Sites container and then the Inter-Site Transports container.

826. Click the IP container. In the details pane, right-click the site link from which you want to remove a site and then click Properties.

827. In the Sites in this site link box, click the site you want to remove from the site link.

828. Click Remove and then click OK.

Remove a Time Source Configured on the Forest-Root PDC Emulator

Use the following procedure to remove a time source configured on the forest-root PDC emulator. Perform the procedure on the PDC emulator.

Requirements

u Credentials: Domain Admins or Local Administrator on the PDC emulator.

u Tools: net time

To remove a time source configured on the forest-root PDC emulator

829. At the command prompt, type the following command and then press ENTER:

net time /setsntp

830. To verify that the manually configured time source has been cleared, at the command prompt, type the following command and then press ENTER:

net time /querysntp

Verify that you receive the following message: “This computer is not currently configured to use a specific SNTP server.”

Remove Active Directory

To use the Active Directory Installation Wizard to remove Active Directory, you must know the password to assign to the local Administrator account of the server after Active Directory is removed. This procedure does not pertain to removing Active Directory from the last domain controller in the domain.

Requirements

u Credentials: Domain Admin

u Tools: Dcpromo.exe

To remove Active Directory

831. In the Run dialog box, type dcpromo and click OK.

832. The Active Directory Installation Wizard appears. Click Next at the Welcome screen.

833. You have an option to select This server is the last domain controller in the domain. If you select this option, the wizard attempts to remove the domain from the forest. Do not select this option. Click Next.

834. At the Administrative Password screen, enter and confirm the password that you want to assign to the local administrator account after Active Directory is removed. Click Next.

835. At the Summary screen, verify that the information is correct and then click Next to proceed with the removal.

836. The wizard proceeds to remove Active Directory. After it finishes, the wizard displays a completion screen. Click Finish to close the wizard.

837. Click Restart to restart the domain controller.

Rename a Member Server

Use the following procedure to rename a member server. You must be logged on locally to perform this procedure. You can either log on to the domain as a member of a domain administrative group or log on to the computer as a member of the local Administrators group. During the procedure, you must provide domain administrative credentials, even if you are already logged on as a domain administrator.

Requirements

u Credentials: Domain Admins

u Tools: System Control Panel

To rename a member server

838. In Control Panel, open System.

839. On the Network Identification tab, click Properties.

840. In Computer name, type a new name for the computer, and then click OK.

841. In the Domain User Name and Password dialog box, type the name and password of a domain administrative account that has permission to rename the computer. A member of Domain Admins has this permission by default.

842. Click OK and then click Yes to restart the computer now or No to restart the computer later.

You must restart the computer for the name change to take effect.

Reset the Computer Account Password on the PDC Emulator

Use this procedure to reset the password for the computer account on the PDC emulator.

Requirements

Credentials: Domain Admins

Tools: Netdom.exe

To reset the computer account password on the PDC emulator

843. At a command prompt, type the following command and press ENTER:

netdom resetpwd /server:<PDC emulator name> /userid:<domain>\administrator /password:*

Restart Disabled Outbound Replication on a Domain Controller

Use this procedure to restart outbound replication on a domain controller on which it has been disabled.

u Credentials: Domain Admins

u Tools: Repadmin.exe (Support Tools)

To restart disabled outbound replication on a domain controller

u At the command prompt, type the following command and then press ENTER:

repadmin /options ServerName -disable_outbound_repl

where ServerName is the name of the domain controller on which you want to restart outbound replication.

Restart the Net Logon Service

Use the command line to restart the Net Logon service. If you are not logged on to the domain controller, then you must use Terminal Services to perform this command.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To restart the Net Logon service

u Open a command prompt, type the following command, and then press ENTER:

net start netlogon

Restore Applicable Portion of SYSVOL from an Alternate Location

If you are authoritatively restoring only a portion of the directory, not the entire directory, it is not necessary to perform this step. However, if the subtree or object that was authoritatively restored contained elements from the SYSVOL, such as a Group Policy object, you should also restore that portion of the SYSVOL authoritatively.

Requirements

u Credentials: local Administrator or Domain Admins

u Tool: N/A

To restore applicable portion of SYSVOL from alternate location if necessary

844. If still in Directory Services Restore Mode, restart in normal mode.

845. After the system restarts and after the SYSVOL share is published (it can take a few minutes before the SYSVOL share and its sub-folders appear on the domain controller), copy the required files and folders from the SYSVOL directory that was copied to the alternate location to the original location. By doing this, the files that were overwritten are replicated to the other domain controllers, so that the SYSVOL is the same as that which was present at the time of backup.

Example: restoring applicable portion of SYSVOL from alternate location

The following example shows how to copy SYSVOL from the alternate location to the original location. Depending on your system, your drive and folder information can vary.

846. Copy the contents of the scripts directory from:

c:\<Alternate Sysvol Location>\sysvol\c_\winnt\Sysvol\Domain\scripts\

847. Add the contents to:

c:\Winnt\SYSVOL\Sysvol\domain\scripts\

848. Copy the contents of the policies directory from:

c:\<Alternate Sysvol Location>\sysvol\c_\winnt\Sysvol\Domain\policies\

849. Add the contents to:

c:\Winnt\SYSVOL\Sysvol\domain\policies\

By restoring the SYSVOL authoritatively, the files on the restored domain controller are authoritative for the domain and replicate to other domain controllers. Changes made to any policy after the backup will be lost.

For example, a Group Policy object by the name of Finance Policy existed at the time of the last backup, and was referenced by a folder in the SYSVOL directory as:

C:\WINNT\SYSVOL\Sysvol\Domain.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}

However, shortly after the last backup, an administrator edited the Finance Policy, and although the properties of the GPO changed, the globally unique identifier (GUID) of the GPO remained the same. As a result, the GPO is still referenced by the same directory name {31B2F340-016D-11D2-945F-00C04FB984F9}.

When the directory is authoritatively restored, the folder {31B2F340-016D-11D2-945F-00C04FB984F9} from the alternate SYSVOL location is copied to the original SYSVOL location. This replaces the old folder and thus the changes the administrator had made after the backup are lost. This step is necessary, however, to maintain the synchronization between Active Directory and SYSVOL.

Restore from Backup Media

Use a good backup containing at least the system state and system disk to restore the server. By performing a non-authoritative restore on Active Directory, you automatically perform a non-authoritative restore of SYSVOL. No additional steps are required.

Requirements

u To restore System State, you must log on at the local computer, or you must enable Terminal Services in Remote Administration mode on the remote domain controller.

u Credentials: local Administrator

u Tool: NTBackup.exe

To restore from backup media

850. In Directory Services Restore Mode, start the Windows 2000 Server Backup utility. Click Start, point to Programs, then point to Accessories, then point to System Tools, and then click Backup.

851. Click the Restore Wizard button, and then click Next.

852. Select the appropriate backup location and ensure that at least the System disk and System State containers are selected.

853. Click the Advanced button. If you do not go through the advanced menu, the restore process will not be successful.

854. Select Original Location in the Restore Files to list, and then click Next.

855. In the Advanced Restore Options window, check the boxes for:

· Restore security.

· Restore junction points, and restore file and folder data under junction points to the original location.

· Preserve existing volume mount points.

For a primary restore of SYSVOL, also check the following box. A primary restore is only required if the domain controller you are restoring is the only domain controller in the domain.

· When restoring replicated data sets, mark the restored data as the primary data for all replicas.

856. Click Finish.

857. When the restore is complete, click Close, and then click Yes to restart the computer.

The system will now restart and will replicate any new information since the last backup with its replication partners.

Restore from Backup Media for Authoritative Restore

The procedure you use to restore from backup media for an authoritative restore is nearly identical to the non-authoritative restore procedure. The only difference is that you do not restart the computer when the restore is complete. Instead, you proceed to the next steps in the process.

Requirements

u To restore System State, you must log on at the local computer, or you must enable Terminal Services in Remote Administration mode on the remote domain controller.

u Credentials: local Administrator

u Tool: NTBackup.exe

To restore from backup media for authoritative restore

858. In Directory Services Restore Mode, start the Windows 2000 Server Backup utility. Click Start, point to Programs, then point to Accessories, then point to System Tools, and then click Backup.

859. Click the Restore Wizard button, and then click Next.

860. Select the appropriate backup location and ensure that at least the System disk and System State containers are selected.

861. Click the Advanced button and ensure you are restoring junction points. If you do not go through the advanced menu, the restore process will not be successful.

862. Select Original Location in the Restore Files to list.

863. In the Advanced Restore Options window, check the boxes for:

· Restore security.

· Restore junction points, and restore file and folder data under junction points to the original location.

· Preserve existing volume mount points.

For a primary restore of SYSVOL, also check the following box. A primary restore is only required if the domain controller you are restoring is the only domain controller in the domain.

· When restoring replicated data sets, mark the restored data as the primary data for all replicas.

864. Click OK and continue through the restore process. A visual progress indicator is displayed.

865. When asked to restart the computer, do not restart.

Restore System State to an Alternate Location

Perform this procedure to allow an authoritative restore of SYSVOL. After the objects are restored, you can delete the files in the alternate location.

Requirements

u Credentials: local Administrator

u Tool: NTBackup.exe

To restore system state to an alternate location

866. Click the Restore tab.

867. Select System State. (You need not restore the system disk to an alternate location.)

868. Ensure that Alternate Location is selected in the Restore Files to drop-down list box and designate the alternate location.

869. When the restore process is finished, close the backup utility.

Restore SYSVOL from an Alternate Location

Perform the following procedure to restore SYSVOL authoritatively.

Requirements

u Credentials: local Administrator or Domain Admins

u Tool: N/A

To restore SYSVOL from an alternate location

870. If still in Directory Services Restore Mode, restart in normal mode.

871. Once the system has been rebooted and after the SYSVOL share is published (it may take a few minutes before the SYSVOL share and its sub-folders appear on the domain controller), copy the required files and folders from the SYSVOL directory that was copied to the alternate location to the original location. By doing this, the files that were overwritten are replicated out to the other domain controllers, so that the SYSVOL is the same as that which was present at the time of backup.

Example: restoring SYSVOL from alternate location

The following example shows how to copy the SYSVOL from the alternate location to the original location. Depending on your system, your drive and folder information may vary.

Copy the contents of the scripts directory from:

c:\<Alternate Sysvol Location>\sysvol\c_\winnt\Sysvol\Domain\scripts\

And add it to:

c:\Winnt\SYSVOL\Sysvol\domain\scripts\

Copy the contents of the policies directory from:

c:\<Alternate Sysvol Location>\sysvol\c_\winnt\Sysvol\Domain\policies\

And add it to:

c:\Winnt\SYSVOL\Sysvol\domain\policies\

By restoring the SYSVOL authoritatively, the files on the restored domain controller will be authoritative for the domain and will replicate to other domain controllers. Changes made to any policy after the backup will be lost.

For example, a Group Policy object by the name of Finance Policy existed at the time of the last backup, and was referenced by a folder in the SYSVOL directory as:

C:\WINNT\SYSVOL\Sysvol\Domain.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}

However, shortly after the last backup, an administrator edited the Finance Policy, and although the properties of the GPO changed, the GUID of the GPO remained the same. As a result, the GPO was still referenced by the same directory name {31B2F340-016D-11D2-945F-00C04FB984F9}.

When the directory is authoritatively restored, the folder {31B2F340-016D-11D2-945F-00C04FB984F9} from the alternate SYSVOL location was copied to the original SYSVOL location. This replaced the old folder and thus the changes the administrator had made after the backup were lost. This step is necessary, however, to maintain the synchronization between Active Directory and SYSVOL.

Seize the Operations Master Role

The Ntdsutil.exe command-line tool allows you to transfer and seize any operations master role. You must use Ntdsutil.exe to seize the schema master, domain naming master, and RID master roles. When you use Ntdsutil.exe to seize an operations master role, it first attempts a transfer from the current role owner. If the current role owner is unavailable, it performs the seizure.

When using Ntdsutil.exe to seize an operations master role, the procedure is nearly identical for all roles. For more information about using Ntdsutil.exe, type ? at the Ntdsutil.exe command prompt.

Requirements

u Credentials: Domain Admins or Enterprise Admins

u Tools: Ntdsutil.exe (system tool)

To seize the operations master role

872. In the Run dialog box, type ntdsutil and press ENTER.

873. At the ntdsutil: prompt, type roles and press ENTER.

874. At the fsmo maintenance: prompt, type connections and press ENTER.

875. At the server connections: prompt, type connect to server servername, where servername is the name of the domain controller that will assume the operation master role, and press ENTER.

876. After you receive confirmation of the connection, type quit and press ENTER to exit the menu..

877. Depending on the role you want to seize, enter the command indicated and press ENTER:

Role	Credentials	Command
Domain Naming Master	Enterprise Admins	seize domain naming master
Schema Master	Enterprise Admins	seize schema master
Infrastructure Master	Domain Admins	seize infrastructure master
PDC Emulator	Domain Admins	seize pdc
RID Master	Domain Admins	seize rid master

The system asks for confirmation. It then attempts to transfer the role. When the transfer fails, some error information appears and the system proceeds with the seizure. After the seizure is complete, a list of the roles and the LDAP name of the server that currently holds each role appears.

During seizure of the RID master, the current role holder attempts to synchronize with its replication partners. If it cannot establish a connection with a replication partner during the seizure operation, it displays a warning and confirms that you want the role seizure to proceed. Click Yes to proceed.

878. Type quit and press ENTER. Type quit and press ENTER to exit ntdsutil.exe.

Set a Manually Configured Time Source on a Selected Computer

Use the following procedure to manually set the time source for a client computer.

Requirements

u Credentials: Domain Admins

u Tools: net time

To set a manually configured time source on a selected computer

879. Ping the SNTP server to ensure that it is reachable from the client. Type the following command and then press ENTER:

ping server

where server is the DNS name or IP address of the SNTP server.

880. At the command prompt, type the following command and then press ENTER:

net time /setsntp:server

where server is the DNS name or IP address of the SNTP server.

881. To verify that the manually configured time source has been set, at the command prompt, type the following command and then press ENTER:

net time /querysntp

Verify that the name of the SNTP server is displayed.

Set the fRSRootPath

Use this procedure to modify the fRSRootPath attribute for a domain controller in Active Directory in order to change the location of the SYSVOL folder on that domain controller. Perform this procedure at the console of the domain controller that is hosting the SYSVOL you are reconfiguring.

Requirements

u Credentials: Domain Admins

u Tools: ADSI Edit

To set the fRSRootPath

882. In the Run dialog box, type adsiedit.msc and press ENTER.

883. Double click Domain NC [machinename], where machinename is the name of this domain controller. Verify that the Domain NC expands to display the domain component (DC=) folder.

884. Click once on the domain component to display the containers and OUs in the right pane. Double-click the Domain Controllers OU to display the containers that represent the domain controllers.

885. Double-click on the container that represents this domain controller (CN=computername) to reveal more containers.

886. Double-click the NTFRS Subscriptions container.

887. Right-click the Domain System Volume container and click Properties.

888. The Properties for this container opens. In the Select which properties to view list, select Mandatory.

889. In the Select a property to view list, select fRSRootPath.

890. In the Edit Attribute box, enter the complete path to the new location where you want to locate SYSVOL. Include the drive letter. Click Set then click OK.

Note

The complete path to the new location is the New Value for row one in Table B.1 that you recorded while gathering the System Volume path information.

891. At a command prompt, change directory to <%systemroot%>\SYSVOL\sysvol.

892. Type DIR and press ENTER. One of the items displayed should be listed as <JUNCTION> followed by the name of the domain.

893. The path in this junction needs to be updated to the new location. Type the following command:

linkd junctionname newpath

where newpath is the New Value you recorded in row four of Table Z.Z while gathering the system volume path information. Press ENTER.

Set the PDC Emulator to not Synchronize Time

Use this procedure to set a PDC emulator so that it does not synchronize time.

Requirements

u Credentials: Domain Admins

u Tools: regedit

To set the PDC emulator to not synchronize

894. At the command prompt, type the following command and then press ENTER:

Regedit

895. Navigate to the registry entry type in the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

896. Change the value to NoSync.

897. Close the registry editor.

Set the Staging Area Path

Use this procedure to modify the fRSStagingPath attribute for a domain controller in Active Directory in order to change the location of the Staging Area folder on that domain controller. Perform this procedure at the console of the domain controller that is hosting the SYSVOL that you must reconfigure.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe, ADSI Edit, Linkd.exe

To set the Staging Area path

898. In the Run dialog box, type adsiedit.msc and press ENTER.

899. Double-click Domain NC [computername], where computername is the name of this domain controller. Verify that the Domain NC expands to display the domain component (DC=) folder.

900. Click the domain component to display the containers and OUs in the right pane. Double-click the Domain Controller OU to display the containers that represent the domain controllers.

901. Double-click the container that represents this domain controller (CN=computername) to display more containers.

902. Double-click the CN=NTFRS Subscriptions container.

903. Right-click the CN=Domain System Volume container and click Properties.

904. The Properties for this container opens. In the Select which properties to view list, select Mandatory.

905. In the Select a property to view list, select fRSStagingPath.

906. In the Edit Attribute box, enter the complete path to the new location where you want to locate the Staging Area folder (the path to the new folder that you created earlier). Include the drive letter. Click Set and then click OK.

907. At a command prompt, change directory to %systemroot%\SYSVOL\staging areas. Type DIR to list the contents. Verify that <JUNCTION> appears in the DIR output.

908. Update the junction so that it points to the new location. Type the following command:

linkd junctionname newpath

where newpath is the same value that you entered for fRSStagingPath earlier. Press ENTER.

Set the SYSVOL Path

Use this procedure to set the new path to the system volume in the registry.

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe

To set the SYSVOL path

909. In the Run dialog box, type regedit and press ENTER.

910. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

911. Double-click SysVol to open the Edit dialog box.

912. For Value Data, enter the new path. Include the drive letter. Click OK.

913. Close the registry editor.

Note

The path in the registry points to the SYSVOL folder located inside the SYSVOL folder that is under the root. When updating the path in the registry, ensure that it still points to the SYSVOL folder inside the SYSVOL folder that is under the root.

Stop and Start Windows Time Service

Use this procedure to stop and start the Windows Time Service.

Requirements

u Credentials: Domain Admins

u Tools: net start, net stop, w32tm.exe

To stop and start the Windows Time Service

914. At a command prompt, type the following command and press ENTER:

net stop w32time

915. At a command prompt, type the following command and press ENTER:

net start w32time

Start or Stop a Service

Use these procedures to start or stop services.

Requirements

Credentials: Local user

Tools: Net start, Net stop

To start ISM

u At a command prompt, type the following command and press ENTER:

net start "intersite messaging"

To start Net Logon

u At a command prompt, type the following command and press ENTER:

net start netlogon

To stop Net Logon

u At a command prompt, type and press ENTER:

net stop netlogon

To start the KDC

u At a command prompt, type the following command and press ENTER:

net start KDC

To stop the KDC

u At a command prompt, type the following command and press ENTER:

net stop KDC

If the KDC cannot stop, set its startup state to disable and restart.

To start the RPC service

u At a command prompt, type the following command and press ENTER:

net start rpcss

Start the File Replication Service

Use this procedure to restart the File Replication service and review the FRS event log to ensure that the restart succeeded.

Requirements

u Credentials: Domain Admins

u Tools: Net.exe, Event Viewer

To start the File Replication service

916. At a command prompt, type net start ntfrs and press ENTER.

917. You can use Event Viewer to verify that NTFRS restarted correctly. Event ID 13501 indicates that the service restarted. Look for event ID 13516 to verify that the domain controller is running and ready for service. If you moved SYSVOL to a new location or relocated the Staging Area folder, look for event IDs 13553 and 13556, which indicate success.

Stop the File Replication Service

Use this procedure to stop the File Replication service.

Requirements

u Credentials: Domain Admins

u Tools: Net.exe

To stop the File Replication service

u At a command prompt, type net stop ntfrs and press ENTER.

Stop the Net Logon Service

Use the command line to stop the Net Logon service. If you are not logged on to the domain controller, you must use Terminal Services to perform this command.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Sites and Services (Administrative Tools)

To stop the Net Logon service

u Open a command prompt, type the following command, and then press ENTER:

net stop netlogon

Stop Windows NT 4.0 Emulation

Use this procedure to stop Windows NT 4.0 emulation.

Requirements

Credentials: Domain Admins

Tools: Regedt32

To stop Windows NT 4.0 emulation

918. In Regedt32, locate the NeutralizeNT4Emulator entry for the following subkey in the registry:

HKEY_LOCAL_MACHINE/System/CCS/Services/Netlogon/Parameters

919. On the Edit menu, click REG_DWORD, type 0x1, and then click OK.

920. Quit Registry Editor.

Synchronize Replication from a Source Domain Controller

Use the following procedure to force replication from an inbound (source) replication partner to a destination domain controller.

Requirements

u Credentials: Domain Admins in the domain of the destination domain controller

u Tools: Active Directory Sites and Services (Administrative Tools)

To synchronize replication from a source domain controller

921. In Active Directory Sites and Services, expand the Sites container, expand the site of the domain controller to which you want to synchronize replication, expand the Servers container, and expand the server object of the domain controller, and then click NTDS Settings.

922. In the From Server column in the details pane, locate the connection object that shows the name of the source domain controller.

923. Right-click the appropriate connection object and then click Replicate Now.

924. Click OK to close the Replicate Now message box.

Repeat the procedure for each source replication partner from which you want to synchronize replication.

Synchronize Replication Partners with the PDC Emulator

Use this procedure to synchronize replication with the PDC emulator.

To synchronize replication partners with the PDC emulator

u At a command prompt, type the following command and press ENTER:

Net time \\server /set /y

Transfer the Domain-Level Operations Master Roles

The three domain-level operations master roles are the PDC emulator, the RID master, and the infrastructure master. You can transfer all of these roles by using the Active Directory Users and Computers console. These procedures are performed by using MMC, although you can also transfer these roles by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer the operations master roles, type ? at the Ntdsutil.exe command prompt.

For more information about transferring operations master roles, see "Managing Flexible Single-Master Operations" in the Distributed Systems Guide of the Windows 2000 Server Resource Kit.

Requirements

u Credentials: Domain Admins

u Tools: Active Directory Users and Computers (Administrative Tools)

To transfer a domain-level operations master role

925. In the Active Directory Users and Computers snap-in, at the top of the console tree in the left pane of the snap-in, right-click Active Directory Users and Computers. Click Connect to Domain Controller.

926. In the list of Available controllers, click the name of the server you to which you want to transfer the role. Click OK.

927. At the top of the console tree in the left pane of the snap-in, right-click Active Directory Users and Computers. Click Operations Masters.

The name of the current operation master role holder appears in the upper box. The name of the server to which you want to transfer the role appears in the lower box.

928. Click the tab that belongs to the role you want to transfer: RID, PDC, or Infrastructure. Verify the computer names that appear and then click Change. Click Yes to transfer the role.

929. Repeat step 4 for each role that you want to transfer.

Note

Hosting the infrastructure master on a global catalog server is not recommended. If you attempt to transfer the infrastructure master role to a domain controller that is a global catalog, the system displays a warning stating that this is not recommended. Click OK to override the warning and transfer the role. If you click Cancel, you do not transfer the role.

930. Click Yes to confirm the transfer, and click OK to confirm that the operation is complete.

Transfer the Forest-Level Operations Master Roles

The two forest-level operations master roles are the domain naming master and the schema master. Any computer that hosts the domain naming master must also be a global catalog server. These procedures are performed by using the Microsoft Management Console (MMC), although you can also transfer these roles by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer the operations master roles, type ? at the Ntdsutil.exe command prompt.

For more information about transferring operations master roles, see "Managing Flexible Single-Master Operations" in the Distributed Systems Guide of the Windows 2000 Server Resource Kit.

Requirements for Transferring the Domain Naming Master

u Credentials: Enterprise Admins

u Tools: Active Directory Domains and Trusts (Administrative Tools)

To transfer the domain naming master

931. In Active Directory Domains and Trusts, right-click Active Directory Domains and Trusts at the root of the tree in the left pane of the console view, and then click Connect to Domain Controller.

932. Ensure that the proper domain name is entered in the Domain box. The available domain controllers from this domain are listed.

933. In the Name column, click the domain controller (to select it) to which you want to transfer the role. Click OK.

934. Right-click Active Directory Domains and Trusts at the root of the tree in the left pane of the console view, and then click Operations Master.

935. The name of the current domain naming master appears in the first text box. The server to which you want to transfer the role should appear in the second text box. If this is not the case, repeat steps 1 through 4.

936. Click Change. To confirm the role transfer, click OK. Click OK to close the message box indicating the transfer took place. Click Close to close the Change Operations Master dialog box.

Requirements for Transferring the Schema Master

u Credentials: Schema Administrator

u Tools: Active Directory Schema snap-in

To transfer the schema master

Before you can use the Active Directory Schema snap-in for the first time, you must register it with the system. If you have not yet prepared the Active Directory Schema snap-in, see “Prepare the Active Directory Schema snap-in” in this guide before you begin this procedure.

937. In the Active Directory Schema snap-in, in the console tree in the left pane, right-click Active Directory Schema, and click Change Domain Controller.

938. In the Change Domain Controller dialog box, click the Specify Name option button, then, in the text box, type the name of the server to which you want to transfer the Schema Master role. Click OK.

939. In the console tree in the left pane of the snap-in, right-click Active Directory Schema. Click Operations Master. The Current Focus box displays the name of the server that is assuming the role. The current schema master is listed in the second box.

940. Click Change. Click OK to confirm your choice. The system confirms the operation. Click OK to confirm that the operation succeeded.

941. Click Cancel to close the Change Schema Master dialog box.

Update Security on the New SYSVOL

This procedure applies the default security settings to the new SYSVOL folders. The settings will be the equivalent of those set by default during Active Directory installation. If additional security settings have been applied to the system volume since Active Directory was installed, you must reapply those settings after completing this procedure.

WARNING

Failure to reapply security changes made after Active Directory was installed might result in unauthorized access to logon and logoff scripts and Group Policy objects.

Requirements

u Credentials: Domain Admins

u Tools: Regedit.exe, Secedit.exe, Notepad.exe

To update security on the new SYSVOL

942. In the Run dialog box, type regedit and press ENTER.

943. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Note the path stored under SysVol.

944. In Control Panel, double-click System.

945. On the Advanced tab, click Environment Variables.

946. Under System Variables, click New.

947. For Variable Name, type sysvol

948. For Variable Value, type path, where path is the path that you noted in step 2. Click OK twice. Click OK again to close Properties.

949. Use Notepad to create a file. Open Notepad and enter the following information:

[Unicode]

Unicode=yes

[Version]

signature="$CHICAGO$"

Revision=1

[Profile Description]

Description=default perms for sysvol

[File Security]

;"%SystemRoot%\SYSVOL",0,"D:AR(A;OICI;FA;;;BA)"

"%Sysvol%",2,"D:P(A;CIOI;GRGX;;;AU)(A;CIOI;GRGX;;;SO)(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"

"%Sysvol%\domain\policies",2,"D:P(A;CIOI;GRGX;;;AU)(A;CIOI;GRGX;;;SO)(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)(A;CIOI;GRGWGXSD;;;PA)"

950. Use this file to apply the security settings to the new SYSVOL folders. Save this file as sysvol.inf.

951. Open a new command prompt. Do not use an existing command prompt that has been open on your desktop, because it will not have the proper environment settings. Change directory to the folder where you saved the sysvol.inf file.

952. At the command prompt, type the following command on one line:

SECEDIT /Configure /cfg sectemplatepath\sysvol.inf /db sectemplatepath\sysvol.db /overwrite

where sectemplatepath is the path to where you saved sysvol.inf. Press ENTER.

Update the Junction Points

Use this procedure to update the junction points in the new SYSVOL folders.

Requirements

u Credentials: Domain Admins

u Tools: Linkd.exe

To update the junction points

953. At a command prompt, change directory to Drive:\Path\SYSVOL\sysvol under the new folders you created for SYSVOL. Use the DIR command to list the contents and verify that the junction point is in place (<JUNCTION> in the DIR output).

954. Type linkd junctionname, where junctionname is the name displayed in the DIR listing and is the fully qualified domain name. Press ENTER. This displays the path to which the junction is linked.

955. The path displayed needs to be updated to the new location. Type the following command:

linkd junctionname newpath\sysvol\sysvol\domain

where newpath is the New Value that you recorded in row four of Table B.1 while gathering system volume path information. Press ENTER.

956. At a command prompt, change directory to Drive:\Path\SYSVOL\staging areas under the new folders you created for SYSVOL. Use the DIR command to list the contents and verify that the junction point is in place (<JUNCTION> in the DIR output).

957. Type linkd junctionname and press Enter.

where junctionname is the name displayed in the DIR listing and is the fully qualified domain name. This displays the path to which the junction is linked.

958. The path displayed needs to be updated to the new location. Type the following command:

linkd junctionname newpath\sysvol\staging\domain

where newpath is the New Value that you recorded in row five of Table B.1 while gathering system volume path information. Press ENTER.

959. Use the DIR command or Windows Explorer to list the folders in the new location and list the folders in the old location. Compare the two lists to ensure that all folders have been created. If any folders are missing at the new location, such as \scripts, recreate them.

Use the Net Time Tool

You can use Net Time to manually configure the time source for a computer. You can also use Net Time to check the time on a remote computer and set the clock of the local computer to match the remote computer.

Requirements

u Credentials: Domain Admins

u Tools: net time

To use Net Time

u At a command prompt, type one of the following commands and press ENTER:

net time [\\computername | /DOMAIN:domainname]

net time /RTSDOMAIN[:domainname] [/set]

net time \\computername /querysntp

net time \\computername /setsntp[:ntp server list]

Note

It is recommended that only one IP address or DNS server name be used at a time with this command. W32Time will only use the first IP address or DNS server name specified even if more than one is listed.

The following talbe describes the parameters available for Net Time.

Parameter	Description
Net time	Displays the time on a time server in this computer's domain.
Net time \\computername	Displays the time on computername.
Net time /domain:domainname	Displays the time on a domain controller in domainname.
Net time /domain /set	Sets this computer's time to match the time on a domain controller in this computer's domain.
Net time /rtsdomain:domainname	Displays the time on a time server in domainname. Note that the /rtsdomain flag does not actually require a time server to be marked as reliable.
Net time /querysntp	Displays the manually configured time source for this computer, if one exists.
Net time /setsntp:ntpserver	Sets the manually configured time source for this computer. It is important to note that only one DNS name or IP address can be specified.
Net time /setsntp	Clears the manually configured time source for this computer, if one has been specified, and then determines the time source from the domain hierarchy.

Use the W32tm Tool

Use the W32tm tool to diagnose problems that can occur with W32Time. If you are going to use the W32tm tool on a domain controller, it is necessary to stop W32Time. Running W32tm and W32Time at the same time on a domain controller generates an error because both are attempting to use the same UDP port. When you finish using W32tm, you must restart W32Time.

Requirements

u Credentials: Domain Admins

u Tools: net start, net stop, w32tm.exe

To use W32tm

960. At a command prompt, type the following command and press ENTER:

net stop w32time

961. At a command prompt, type the following command and press ENTER:

W32tm [-tz | -s [computer] | -adj | -adjoff | -source | -once] [-test] [-v] [-p port] [-period freq]

The following table describes the parameters available for w32tm.

Parameter	Description
-tz	Prints the local time zone information, and then exits.
-s computer	Forces computer (or the local computer if none is specified) to resynchronize, and then exits.
-adj	Sets the computer's system clock frequency to the last frequency determined during synchronization, and then exits.
-adjoff	Sets the computer's system clock frequency as the system default, and then exits.
-source	Chooses a synchronization source, and then exits. Note that you choose a source before each synchronization, so this is useful only in showing that a source cannot be found.
-once	Synchronizes once, and then exits. Otherwise, runs continuously as a client, synchronizing the local clock until CTRL+C is pressed.

962. At a command prompt, type the following command and press ENTER:

net start w32time

Verify Active Directory Restore

After the restore is completed, you can either restart the server in normal operation mode and perform basic verification, or continue with the advanced verification. The advanced option is not usually required, and should be used with caution, as incorrect use of the ntdsutil utility can corrupt the Active Directory database. Both processes are explained below.

Requirements

u You must log on at the local computer, or you must enable Terminal Services in Remote Administration mode on the remote domain controller.

u Credentials:

· Basic: Domain Admins or local Administrator

· Advanced: local Administrator

u Tool: NTBackup.exe

To perform basic Active Directory verification

963. After the restore operation completes, restart the computer in normal operational mode. Active Directory and the Certificate Server automatically detect that they have been recovered from a backup. They perform an integrity check and re-index the database.

964. After you are able to log on to the system, browse the directory. Verify that all of the user and group objects that were present in the directory prior to backup are restored. Similarly, verify that files that were members of a FRS replica set and certificates that were issued by the Certificate Server are present.

To perform advanced Active Directory verification

Caution

The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first, as described in this guide.

965. Immediately after performing the restore operation, restart the server in Directory Service Repair Mode.

966. After the system starts, log on using the local Administrator account.

967. Verify that the Active Directory is in a state consistent with having been recovered from a backup. To do this, check for a specific registry subkey.

In the Run dialog box, type Regedit and click OK.

968. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS.

969. Check that the subkey called Restore In Progress is present. This subkey is automatically generated by Windows NT Backup, and indicates to the Active Directory service that the database files have been restored and that Active Directory service must perform a consistency check and re-index the next time the directory is started. This subkey is automatically removed upon completion of this check. Do not add or delete this subkey.

970. Use Ntdsutil.exe to check for the recovered Active Directory database files. At the command prompt, type ntdsutil and press ENTER.

971. At the ntdsutil: prompt, type files and press ENTER.

972. At the file maintenance: prompt, type info and press ENTER.

973. If the Active Directory files have been recovered successfully, you should see output listing the paths for the database, the backup directory, the working directory and the log directory, as well as a list of the log file names and file sizes. Do not select any other options.

974. After you confirm that Active Directory has been restored from the backup and that the registry subkey is present, restart the server in normal mode.

975. When the computer is restarted in normal mode, Active Directory automatically detects that it has been recovered from a backup and performs an integrity check and re-indexes the database. After you are able to log on to the system, browse the directory and verify that all user and group objects that were present in the directory prior to backup are restored.

Verify a Connection Object

Use this procedure to verify connection objects between domain controllers.

Requirements

Credentials: Domain Admins

Tools: Active Directory Sites and Services

To verify that a connection object exists

976. In Active Directory Sites and Services, right-click Active Directory Sites and Services and then click Connect to Domain Controller.

977. Expand Sites, the name of the site, Servers, the name of the server, and then click NTDS Settings.

978. In the details pane, verify that a connection object from the appropriate server exists.

Verify Communication with Other Domain Controllers

This test verifies that domain controllers can be located.

Requirements

u Credentials: Domain User

u Tools: Netdiag.exe

To verify communication with other domain controllers

Note

For a more detailed response from this command, you can use the verbose option. Add /v to the end of the command to see the detailed response.

u At a command prompt, type the following command and press ENTER:

netdiag /test:dsgetdc

If domain controllers are successfully located, the last line of the response is DC discovery test……..: Passed. The verbose option lists the specific domain controllers that are located.

If the test fails, do not attempt any additional steps until you determine and fix the problem that prevents communication with other domain controllers.

Verify DNS Records

Use this procedure to use the DNS snap-in to verify DNS records.

Requirements

Credentials: Domain Admins or DnsAdmins

Tools: DNS snap-in

To verify DNS records

979. In the DNS MMC snap-in, navigate to the _msdcs.company.com zone.

980. Verify that the appropriate records exist.

Verify DNS Records by Using Dcdiag.exe

Use this procedure to view DNS records on a domain controller.

Requirements

u Credentials: Domain Admins

u Tools: Dcdiag.exe

To verify DNS records by using Dcdiag.exe

981. Verify CNAME and A resource records. At a command prompt on the destination domain controller or through a terminal services connection, type the following command and press ENTER:

dcdiag /test:connectivity /s:<domain controller>

982. If the CNAME and A resource records are missing, stop and start Net Logon on the source domain controller.

983. Again, verify CNAME and A resource records.

Verify DNS Registration and Functionality

This test verifies that DNS is functioning so that other domain controllers can be located.

Requirements

u Credentials: Domain User

u Tools: Netdiag.exe

To verify DNS registration and functionality

Note

For a more detailed response from this command, you can use the verbose option. Add /v to the end of the command to see the detailed response

u At a command prompt, type the following command and press ENTER:

netdiag /test:dns

If DNS is functioning, the last line of the response is DNS Test…..: Passed. The verbose option lists specific information about what was tested. This information can help troubleshooting if the test fails.

If the test fails, do not attempt any additional steps until you determine and fix the problem that prevents proper DNS functionality.

Verify Domain Membership for a New Domain Controller

This test verifies that a new domain controller successfully has become a member of the domain.

Note

You can get a more detailed response from this command by using the verbose option. Add /v to the end of the command listed to see the detailed response.

Requirements

u Credentials: Domain User

u Tools: Netdiag.exe

To verify domain membership for a new domain controller

984. At a command prompt, type

netdiag /test:member

985. Towards the bottom of the screen you should see the message "Domain membership test Passed" if the test was successful. If you use the /v option it will list the name of the domain controller, its role, the name of the domain and a number of other statistics about the new domain controller.

Verify Global Catalog DNS Registrations

To verify that a server is advertised as a global catalog server, use the DNS snap-in to verify the presence of DNS SRV resource records for the server. Restart the global catalog server prior to checking DNS registrations.

Requirements

u Credentials: Domain Users

u Tools: DNS snap-in (Administrative Tools)

u Global catalog server has been restarted since replication completed.

To verify the presence of global catalog-specific DNS SRV resource records

986. In the DNS snap-in, connect to a domain controller in the forest root domain.

987. Expand Forward Lookup Zones and then expand the forest root domain.

988. Click the _tcp container. In the details pane, look in the Name column for _gc and in the Data column for the name of the server. The records that begin with _gc are global catalog SRV records.

Verify Global Catalog Readiness

When a global catalog server has satisfied replication requirements, the isGlobalCatalogReady rootDSE attribute is set to TRUE. Use Ldp.exe or Nltest.exe to view this value.

Requirements

u Credentials: Domain Users

u Tools: Ldp.exe (Support Tools)

To use Ldp.exe to verify global catalog readiness

989. In Ldp.exe, on the Connection menu, click Connect.

990. In the Connect box, type the name of the server whose global catalog readiness you want to verify.

991. In the Port box, if 389 is not showing, type 389.

992. If the Connectionless box is selected, clear it and then click OK.

993. In the details pane, verify that the isGlobalCatalogReady attribute has a value of TRUE.

994. On the Connection menu, click Disconnect and then close Ldp.exe.

Requirements

u Credentials: Domain Users

u Tools: Nltest.exe (Support Tools)

To use Nltest.exe to verify global catalog server readiness

995. At a command prompt, type the following, using the name of the server you have added the global catalog to and the domain of the server:

nltest /server:ServerName /dsgetdc:DomainName

996. In the Flags: line of the output, if GC appears, then the global catalog server has satisfied its replication requirements.

Verify Network Configuration

Use this procedure to view network configuration settings on the local computer.

Requirements

Credentials: local Administrator account

Tools: Network Connections dialog box, Ipconfig.exe, Ping.exe

To verify network configuration

997. In Control Panel, double-click Network Connections.

998. In the Network Connections dialog box, select Local Area Connection, or the appropriate connection name for each network adapter.

999. In Local Area Connection Status, verify that the status is connected, and click Properties.

1000. In Local Area Connection Properties, verify that the appropriate protocols are bound to the adapter. At a minimum, the box under This connection uses the following items: must contain Internet Protocol (TCP/IP).

1001. Select Internet Protocol (TCP/IP) and click Properties. Verify that the configuration is correct, based on your organization’s standards and requirements.

1002. At a command prompt on the local computer, type the following command and press ENTER:

ipconfig /all

1003. Review the output and verify that the reported settings reflect the Local Area Connection Properties information above. For example, if the connection properties indicate that the computer obtains an IP address automatically from DHCP, make sure that the Ipconfig command is not reporting an Automatic Private IP Addressing (APIPA) address (an IP address of 169.254.x.x, with a subnet mask of 255.255.0.0), which can indicate no connectivity to the network or a problem with a DHCP server.

1004. Ping the loopback address to verify that TCP/IP is installed and configured correctly on the local computer. At a command prompt on the local computer, type the following command and press ENTER:

ping 127.0.0.1

If this fails, the IP stack is not responding. This might be because the TCP drivers are corrupted, the network adapter is not working, or another service is interfering with IP.

1005. Ping the IP address of the local computer to verify that it was added to the network correctly. Note that if the routing table is correct, this simply forwards the packet to the loopback address of 127.0.0.1. At a command prompt on the local computer, type the following command and press ENTER:

ping <IP address of local computer>

Verify Network Connectivity

Use this procedure to test network connectivity between two computers, and to verify that any routers between them are functioning properly.

Requirements

Credentials: User

Tools: Ping.exe, Pathping.exe

To verify network connectivity

1006. Ping the IP address of the default gateway to verify that the default gateway is functioning and that you can communicate with a computer on the local network.

oo. Obtain the default gateway address. At a command prompt on the local computer, type the following command and press ENTER:

ipconfig

pp. Ping the default gateway. At a command prompt on the local computer, type the following command and press ENTER:

ping <IP address of default gateway>

1007. Ping the IP address of a computer on a different subnet to verify that you can communicate through a router. At a command prompt on the local computer, type the following command and press ENTER:

ping <IP address of remote computer>

1008. Ping the host name of a computer on a different subnet to verify that you can resolve a remote host name. At a command prompt on the local computer, type the following command and press ENTER:

ping <host name of remote computer>

1009. Run a PathPing analysis to a remote computer to verify that the routers on the way to the destination are functioning correctly. At a command prompt on the local computer, type the following command and press ENTER:

pathping <IP address of remote computer>

Verify Replication is Functioning

These tests verify that different aspects of the replication topology are working properly. They check to see that objects are replicating and they verify that the proper logon permissions are set to allow replication to occur.

Note

For this set of tests, the /v option is available, however, it does not display any significant additional information.

Requirements

u Credentials: Domain Admin

u Tools: Dcdiag.exe

To verify replication is functioning

1010. To check if replication is working, at a command prompt, type the following command and press ENTER:

dcdiag /test:replications

The /v option does not display any significant additional information for this test. Messages indicate that the connectivity and replications tests passed.

1011. To verify that the proper permissions are set for replication, at a command prompt, type the following command and press ENTER:

dcdiag /test:netlogons

Messages indicate that the connectivity and netlogons tests passed.

Verify an SPN

Use this procedure to verify the Service Principal Name (SPN) of a replication partner for a domain controller.

Requirements

Credentials: Domain Admins

Tools: Setspn.exe

To verify an SPN

u At a command prompt on the local domain controller, type the following command and press ENTER:

SETSPN –L <replication partner>

This displays the SPN names of the specified domain controller in the local Active Directory. In the output, search for the SPN name used for replication.

Verify Successful Replication to a Domain Controller

Use Repadmin.exe to verify success of replication to a specific domain controller. Run the /showreps command on the domain controller that receives replication (the destination domain controller). In the output under INBOUND NEIGHBORS, Repadmin.exe shows the Lightweight Directory Access Protocol (LDAP) distinguished name of each directory partition for which inbound directory replication has been attempted, the site and name of the source domain controller, and whether it succeeded or not, as follows:

u Last attempt @ YYYY-MM-DD HH:MM.SS was successful.

u Last attempt @ [Never] was successful.

Requirements

u Credentials: Domain Admins in the domain of the destination domain controller

u Tools: Repadmin.exe (Support Tools)

To verify successful replication to a domain controller

1012. At a command prompt, type the following command and then press ENTER:

repadmin /showreps ServerName /u:DomainName\UserName /pw:*

where ServerName is the name of the destination domain controller, DomainName is the single-label name of the domain of the destination domain controller (you do not have to use a fully-qualified DNS name), and UserName is the name of an administrative account in that domain.

1013. When prompted, type the password for the user account you provided, and then press ENTER.

The last successful attempt should agree with the replication schedule for intersite replication, or should be within the last hour for intrasite replication. When replication has never occurred, the message indicates that the last success was never.

If Repadmin.exe reports any of the following conditions, contact a superior:

u The last successful intersite replication was prior to the last scheduled replication.

u The last intrasite replication was longer than one hour ago.

u Replication was never successful.

Verify that an IP Address Maps to a Subnet and Determine the Site Association

Use this procedure to determine the site to which you want to add a server object prior to installing Active Directory, or to verify the appropriate site prior to moving a server object to it.

To be associated with a site, the IP address of a domain controller must map to a subnet object that is defined in Active Directory. The site to which the subnet is associated is the site of the domain controller.

The subnet address, which is computed from the IP network address and the subnet mask, is the name of a subnet object in Active Directory. When you know the subnet address, you can locate the subnet object and determine the site to which the subnet is associated.

Requirements

u Credentials: Domain Users

u Tools:

· My Network Places

· Active Directory Sites and Services (Administrative Tools)

To verify that an IP address maps to a subnet and determine the site association

1014. Log on locally or open a Terminal Services connection to the server for which you want to check the IP address.

1015. On the desktop, right-click My Network Places and then click Properties.

1016. In the Network and Dial-up Connections dialog box, right-click Local Area Connection and then click Properties.

1017. Double-click Internet Protocol (TCP/IP).

1018. Use the values in IP address and Subnet mask to calculate the subnet address.

1019. In Active Directory Sites and Services, expand the Sites container and then click the Subnets container.

1020. In the Name column in the details pane, find the subnet object that matches the subnet address.

1021. In the Site column, note the site to which the IP subnet address is associated.

If the site that appears in the Site box is not the appropriate site, contact a supervisor and find out whether the IP address is incorrect or whether to move the server object to the site indicated by the subnet.

Verify that Windows Time Service is Synchronizing Time

Use this procedure to verify that the Windows Time Service is synchronizing time.

Requirements

u Credentials: Domain Admins

u Tools: net start, net stop, w32tm.exe

To verify that Windows Time Service is synchronizing time

1022. At a command prompt, type the following command and press ENTER:

net stop w32time

1023. At a command prompt, type the following command and press ENTER:

w32tm -once -test

1024. At a command prompt, type the following command and press ENTER:

net start w32time

Verify the Existence of the Operations Masters

This test verifies that the operations masters can be located and that they are online and responding.

Requirements

u Credentials: Domain User

u Tools: Dcdiag.exe

To verify the existence of the operations masters

Note

You can use these tests prior installing Active Directory as well as after installing the directory. To perform the test prior to installing Active Directory, you must use the /s option to indicate the name of a domain controller to use for the test. You do not need the /s option to perform the test after installing Active Directory. The test automatically runs on the local domain controller where you are performing the tests. The commands listed in this procedure show the /s option. If you are performing this test after installing Active Directory, omit the /s option.

For a more detailed response from this command, you can use the verbose option. Add /v to the end of the command to see the detailed response.

1025. To ensure the operations masters can be located, at a command prompt, type the following command and press ENTER:

dcdiag /s:domaincontroller /test:knowsofroleholders

where domaincontroller is the name of a domain controller in the domain in which you want to add the new domain controller. The verbose option provides a detailed list of the operations masters that were tested. Near the bottom of your screen, a message confirms that the test succeeded. If you use the verbose option, look carefully at the bottom part of the displayed output. The test confirmation message appears immediately after the list of operations masters.

1026. To test to ensure the operations masters are functioning properly and available on the network, at a command prompt, type the following command and press ENTER:

dcdiag /s:domaincontroller /test:fsmocheck

where domaincontroller is the name of a domain controller in the domain in which you want to add the new domain controller. The verbose option provides a detailed list of the operations masters that were tested. Near the bottom of your screen, a message confirms that the test succeeded.

If these tests fail, do not attempt any additional steps until you determine and fix the problem that prevents locating operations masters and verifying that they are functioning properly.

View Replication Metadata of an Object

Replication metadata identifies the history of attributes that have been replicated for a specified object. Use this procedure to identify times, dates, and update sequence numbers (USNs) of attribute replications, as well as the domain controller on which replication originated.

u Credentials: Domain Admins

u Tools: Repadmin.exe (Support Tools)

To view replication metadata of an object

u Open a command prompt and type the following command, and then press ENTER:

repadmin /showmeta distinguishedName ServerName /u:DomainName\UserName /pw:*

where:

· distinguishedName is the LDAP distinguished name of an object that exists on ServerName.

· DomainName is the domain of ServerName.

· UserName is the name of an administrative account in that domain.

If you are logged on as an administrator in the domain of the destination domain controller, omit the /u: and /pw: switches.

View the Current Operations Master Role Holders

To view the current operations master role holders, use Ntdsutil.exe with the roles option. This option displays a list of all current role holders.

Requirements

u Credentials: User or Administrator

u Tools: Ntdsutil.exe (system tool)

To view the current operations master role holder

1027. In the Run dialog box, type ntdsutil and press ENTER.

1028. At the ntdsutil: prompt, type roles and press ENTER.

1029. At the fsmo maintenance: prompt, type connections and press ENTER.

1030. At the server connections: prompt, type connect to server servername, where servername is the name of the domain controller that belongs to the domain containing the operations masters.

1031. After receiving confirmation of the connection, type quit and press ENTER to exit this menu.

1032. At the fsmo maintenance: prompt, type select operation target and press ENTER.

1033. At the select operations target: prompt, type list roles for connected server and press ENTER. The system responds with a list of the current roles and the Lightweight Directory Access Protocol (LDAP) name of the domain controllers that are currently assigned to host each role.

1034. Type quit and press ENTER to exit each prompt in Ntdsutil.exe. Type quit and press ENTER at the ntdsutil: prompt to close the window.

View the List of Preferred Bridgehead Servers

To see all servers that have been selected as preferred bridgehead servers in a forest, you can view the bridgeheadServerListBL attribute on the IP container object.

Requirements

u Credentials: Domain Users

u Tools: ADSI Edit (Windows Support Tools)

To view the list of preferred bridgehead servers

1035. In ADSI Edit, expand Configuration Container and then expand CN=Configuration,DC=ForestRootDomainName, CN=Sites, and CN=Inter-Site Transports.

1036. Right-click CN=IP and then click Properties.

1037. In the Select a property to view box, click bridgeheadServerListBL.

The Value(s) box displays the distinguished name for each server object that is currently selected as a preferred bridgehead server in the forest. If the value is <not set>, no preferred bridgehead servers are currently selected.