Vous êtes sur la page 1sur 518

Windows Server 2003 Active Directory Operations Guide

Microsoft Corporation Published: June 2005 Updated: July 2006

Abstract
This operations guide for the Microsoft Windows Server 2003 Active Directory directory service provides step-by-step, task-oriented information for Windows Server 2003 and Windows Server 2003 with Service Pack 1 (SP1) technologies. This operations guide is designed to provide information technology (IT) operators and administrators with prescriptive guidance for operating, managing, and troubleshooting Active Directory servers.

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

2005 - 2006 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Windows Server, and Active Directory are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

Contents
Windows Server 2003 Active Directory Operations Guide...................................................1 Contents.............................................................................................................................3 Active Directory Operations Guide Administering Active Directory Operations .......................................................................21 ............................................................21

Introduction to Administering Active Directory .......................................................22 When to Use This Guide................................................................................................22 How to Use this Guide...................................................................................................23 New in This Guide for Administering Active Directory ............................................24 New Content.................................................................................................................24 Updated Content...........................................................................................................24 Administering Domain and Forest Trusts Introduction to Domain and Forest Trusts Best Practices for Domain and Forest Trusts Managing Domain and Forest Trusts ..............................................................25 .............................................................25 ........................................................26 ....................................................................27

Creating Domain and Forest Trusts ......................................................................27 New Trust Wizard Terminology......................................................................................28 Known Issues for Creating Domain and Forest Trusts Creating External Trusts ..........................................29

.......................................................................................31 ......................32 ...................34 .......................36 ....................38

Create a one-way, incoming, external trust for one side of the trust Create a one-way, incoming, external trust for both sides of the trust Create a one-way, outgoing, external trust for one side of the trust Create a one-way, outgoing, external trust for both sides of the trust Create a two-way, external trust for one side of the trust Create a two-way, external trust for both sides of the trust

......................................40 ....................................42

Creating Shortcut Trusts

.......................................................................................44 ......................45 ...................47 .......................49 ....................51

Create a one-way, incoming, shortcut trust for one side of the trust Create a one-way, incoming, shortcut trust for both sides of the trust Create a one-way, outgoing, shortcut trust for one side of the trust Create a one-way, outgoing, shortcut trust for both sides of the trust Create a two-way, shortcut trust for one side of the trust Create a two-way, shortcut trust for both sides of the trust Creating Forest Trusts

......................................52 ....................................54

..........................................................................................56 ..........................58 .......................60 ..........................62 ........................64

Create a one-way, incoming, forest trust for one side of the trust Create a one-way, incoming, forest trust for both sides of the trust Create a one-way, outgoing, forest trust for one side of the trust Create a one-way, outgoing, forest trust for both sides of the trust Create a two-way, forest trust for one side of the trust Create a two-way, forest trust for both sides of the trust Creating Realm Trusts

..........................................66 .......................................68

..........................................................................................70 ...............................................................71 ...............................................................72

Create a one-way, incoming, realm trust Create a one-way, outgoing, realm trust Create a two-way, realm trust

...............................................................................74 .................................................................75 ..............................................................................75

Configuring Domain and Forest Trusts Validating and removing trusts

Validate a trust .....................................................................................................76 To validate a trust..........................................................................................................76 Remove a manually created trust .........................................................................78 To remove a manually created trust...............................................................................78 Modifying Name Suffix Routing Settings Modify the routing status of a name suffix ...............................................................80 .............................................................81

To modify the routing status of a name suffix.................................................................81 See Also........................................................................................................................82 Enable or disable an existing name suffix for routing ............................................82 To enable or disable an existing name suffix for routing.................................................82 See Also........................................................................................................................83 Exclude name suffixes from routing to local forests ..............................................83 To exclude name suffixes from routing to local forests...................................................83 See Also........................................................................................................................84 Securing Domain and Forest Trusts Configuring SID Filtering Settings Disable SID filtering Reapply SID filtering .....................................................................84 .........................................................................84

..............................................................................................86 ............................................................................................87 .......................................................89

Configuring Selective Authentication Settings

Enable selective authentication over an external trust ..........................................90 To enable selective authentication over an external trust...............................................90 Enable selective authentication over a forest trust ................................................91 To enable selective authentication over a forest trust.....................................................92 See Also........................................................................................................................92 Enable domain-wide authentication over an external trust ....................................92 To enable domain-wide authentication over an external trust.........................................93 Enable forest-wide authentication over a forest trust ............................................94 To enable forest-wide authentication over a forest trust.................................................94 Grant the Allowed to Authenticate permission on computers in the trusting domain or forest ......................................................................................................................................95 To grant the Allowed to Authenticate permission on computers in the trusting domain or forest..........................................................................................................................96 Appendix: New Trust Wizard Pages .....................................................................96 Direction of Trust...........................................................................................................96 Sides of Trust................................................................................................................99 Administering the Windows Time Service ...........................................................100 ....................................101

Introduction to Administering the Windows Time Service

Managing the Windows Time Service Configuring a time source for the forest

.................................................................102 ..............................................................102 ................................104 105 .....106 ......107

Configure the Windows Time service on the PDC emulator

Change the Windows Time service configuration on the previous PDC emulator Configure a domain controller in the parent domain as a reliable time source Configure the PDC emulator to synchronize from its internal hardware clock Disable the Windows Time service

.....................................................................108 .....................................109 ..........................109 ..............111

Configuring Windows-based clients to synchronize time Configure a manual time source for a selected client computer

Configure a client computer for automatic domain time synchronization Restoring Windows Time service to default settings

............................................112 ..................112

Restore Windows Time service on local computer to default settings Administering SYSVOL

.......................................................................................113 ................................................................113

Introduction to Administering SYSVOL Managing SYSVOL

.............................................................................................117 .............................................118

Changing the Space Allocated to the Staging Area Stop the File Replication service

.........................................................................119 .......................................119

Change the space allocated to the Staging Area folder Start the File Replication service Relocating the Staging Area Identify replication partners

........................................................................120 ...............................................................................120 ................................................................................122 ............................................................123 ...................................................124

Check the status of the shared SYSVOL Verify replication with other domain controllers

Gather the SYSVOL path information .................................................................124 To gather the system volume path information.............................................................125

Reset the File Replication service staging folder to a different logical drive Relocating SYSVOL Manually Identify replication partners

.........127

............................................................................130 ................................................................................132 ............................................................132 ...................................................134

Check the status of the shared SYSVOL Verify replication with other domain controllers

Gather the SYSVOL path information .................................................................134 To gather the system volume path information.............................................................135 Stop the File Replication service Create the SYSVOL folder structure Set the SYSVOL path Set the staging area path ........................................................................137 ...................................................................138

.........................................................................................139 ...................................................................................139 .......................141

Prepare a domain controller for nonauthoritative SYSVOL restart Update security on the new SYSVOL Start the File Replication service Updating the System Volume Path

.................................................................142 ........................................................................144 .....................................................................145

Gather the SYSVOL path information .................................................................145 To gather the system volume path information.............................................................146 Stop the File Replication service Set the SYSVOL path Set the staging area path Start the File Replication service Restoring and Rebuilding SYSVOL Identify replication partners ........................................................................148

.........................................................................................149 ...................................................................................150 ........................................................................151 ....................................................................152 ................................................................................153 ............................................................154 ...................................................155 ...........155

Check the status of the shared SYSVOL Verify replication with other domain controllers

Restart the domain controller in Directory Services Restore Mode locally

See Also......................................................................................................................156 Gather the SYSVOL path information .................................................................156 To gather the system volume path information.............................................................157 Stop the File Replication service ........................................................................159 .......................160

Prepare a domain controller for nonauthoritative SYSVOL restart Import the SYSVOL folder structure Start the File Replication service Administering the Global Catalog

....................................................................161 ........................................................................164 .......................................................................164

Introduction to Administering the Global Catalog ................................................165 Global Catalog Placement...........................................................................................165 Initial Global Catalog Replication.................................................................................165 Global Catalog Readiness...........................................................................................166 Global Catalog Removal..............................................................................................166 See Also......................................................................................................................167 Managing the Global Catalog Configuring a Global Catalog Server .............................................................................167 ..................................................................167 ......................168 ...............................169

Determine whether a domain controller is a global catalog server Designate a domain controller to be a global catalog server Monitor global catalog replication progress Determining Global Catalog Readiness

.........................................................169 ..............................................................170

Verify global catalog readiness ...........................................................................171 To verify global catalog readiness................................................................................171 Verify global catalog DNS registrations Removing the Global Catalog Clear the global catalog setting ...............................................................172

.............................................................................173 ..........................................................................173 ..................................................174 ..............................................................175 .......................................175

Monitor global catalog removal in Event Viewer Administering Operations Master Roles

Introduction to Administering Operations Master Roles

Guidelines for Role Placement....................................................................................176 Guidelines for Role Transfer........................................................................................179 Managing Operations Master Roles Designating a standby operations master ...................................................................180 ...........................................................181 ......................182 .............................183 ............................184

Determine whether a domain controller is a global catalog server Create a connection object on the current operations master Create a connection object on the standby operations master

Verify successful replication to a domain controller .............................................184 See Also......................................................................................................................187 Transferring an operations master role ...............................................................187

Verify successful replication to a domain controller .............................................189 See Also......................................................................................................................192 Determine whether a domain controller is a global catalog server Install the Schema snap-in Transfer the schema master Transfer the domain naming master ......................192

.................................................................................192 ...............................................................................193 ...................................................................194 .............................................195 .................................................196

Transfer the domain-level operations master roles View the current operations master role holders Seizing an operations master role

......................................................................197

Verify successful replication to a domain controller .............................................198 See Also......................................................................................................................201 Seize the operations master role ........................................................................201 .................................................203

View the current operations master role holders

Reducing the workload on the PDC emulator master .........................................204 Adjusting the Weight for DNS SRV Records in the Registry.........................................204 Adjusting the Priority for DNS SRV Records in the Registry.........................................205 Change the weight for DNS SRV records in the registry .....................................206

Change the priority for DNS SRV records in the registry Administering Active Directory Backup and Restore

.....................................207 ...........................................208

Introduction to Administering Active Directory Backup and Restore ....................208 System State Components..........................................................................................208 Purpose of Performing Regular Backups.....................................................................209 Restore Requirements and Recommendations............................................................210 Backup Guidelines.......................................................................................................210 Backup Frequency.......................................................................................................212 Backup Latency Interval..............................................................................................213 See Also......................................................................................................................214 Managing Active Directory Backup and Restore .................................................214

Backing Up Active Directory Components ..........................................................214 Naming Backup Files...................................................................................................214 See Also......................................................................................................................216 Back up system state .........................................................................................216 See Also......................................................................................................................219 Back up system state and the system disk .........................................................219 See Also......................................................................................................................220 Performing a Nonauthoritative Restore of a Domain Controller ...........................221 See Also......................................................................................................................222 Restart the domain controller in Directory Services Restore Mode locally ...........222 See Also......................................................................................................................223 Restart the domain controller in Directory Services Restore Mode Remotely ......223 See Also......................................................................................................................225 Restore from backup media ...............................................................................225 See Also......................................................................................................................226 Verify Active Directory restore .............................................................................227

Performing an Authoritative Restore of Active Directory Objects .........................227 Group Membership Restoration Following Authoritative Restore..................................228 Authoritative Restore Improvements in Windows Server 2003 SP1.............................229 Procedures for Domain Controllers Running Windows Server 2003 with SP1..............230 Procedures for Domain Controllers Running Windows Server 2003 with No Service Pack Installed...................................................................................................................231

Restore from backup media ...............................................................................233 See Also......................................................................................................................234 Mark the object or objects authoritative ..............................................................234

Synchronize replication with all partners .............................................................237 See Also......................................................................................................................238 Run an LDIF file to recover back-links ................................................................238 See Also......................................................................................................................238 Restart the domain controller in Directory Services Restore Mode locally ...........239 See Also......................................................................................................................239 Create an LDIF file for recovering back-links for authoritatively restored objects . 239 See Also......................................................................................................................240 Turn off inbound replication ................................................................................241 See Also......................................................................................................................241 Turn on inbound replication ................................................................................241 See Also......................................................................................................................242 Performing an Authoritative Restore of an Application Directory Partition ............242

Restore from backup media ...............................................................................243 See Also......................................................................................................................244 Mark the application directory partition as authoritative Performing an Authoritative Restore of a Group Policy Object Restore a Group Policy Object .......................................245 ............................246

...........................................................................247

Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup ...........................................................................................................247 Restore from backup media ...............................................................................249 See Also......................................................................................................................251 Verify Active Directory restore .............................................................................251 .......................................252

Restoring a Domain Controller Through Reinstallation Clean up server metadata Delete a Server object from a site

..................................................................................253 ......................................................................256

Delete a Computer object from the Domain Controllers OU ................................257 See Also......................................................................................................................257 Verify DNS registration and functionality .............................................................258 ...........................................258 ..................................................259

Verify communication with other domain controllers Verify the availability of the operations masters Install Active Directory

........................................................................................260 ......................................................................262

Administering Intersite Replication

Introduction to Administering Intersite Replication ...............................................262 The KCC and Replication Topology.............................................................................263 Managing Intersite Replication Adding a New Site ...........................................................................264

..............................................................................................264 ..........................................265 .............265

Create a site object and add it to an existing site link

Create a subnet object or objects and associate them with the new site Associate an existing subnet object with the new site Create a site link object and add the appropriate sites Remove the site from the site link Linking Sites for Replication

.........................................266 ........................................267

.......................................................................267 ...............................................................................268 ........................................269

Create a site link object and add the appropriate sites Determine the ISTG role owner for a site Generate the replication topology on the ISTG Changing Site Link Properties

............................................................269 ...................................................270

............................................................................271

Configure the site link schedule to identify times during which intersite replication can occur ....................................................................................................................................272 Configure the site link interval to identify how often replication polling can occur during the schedule window ............................................................................................272 Configure the site link cost to establish a priority for replication routing Determine the ISTG role owner for a site ...............273

............................................................274

Generate the replication topology on the ISTG

...................................................274

Moving a Domain Controller to a Different Site ...................................................275 TCP/IP Settings...........................................................................................................275 Preferred Bridgehead Server Status............................................................................276 Change the static IP address of a domain controller Create a delegation for a domain controller ...........................................277

........................................................278 . .279

Verify that an IP address maps to a subnet and determine the site association Determine whether the server is a preferred bridgehead server Configure the server to not be a preferred bridgehead server Move the Server object to the new site Removing a Site

..........................280 .............................281

...............................................................282

.................................................................................................282 .........................................284

Determine whether a Server object has child objects Delete a Server object from a site Delete the Site Link object

......................................................................285 ..................................................................................285 ..................................286

Associate the subnet or subnets with the appropriate site Delete the Site object

.........................................................................................287 ............................................................287 ...................................................288 ......................................................288 ...............................289

Determine the ISTG role owner for a site Generate the replication topology on the ISTG Administering the Active Directory Database

Introduction to Administering the Active Directory Database Managing the Active Directory Database

............................................................290

Relocating Active Directory Database Files ........................................................291 Disk space requirements for relocating Active Directory database files........................292 Determine the database size and location online Determine the database size and location offline ................................................294 ................................................295 ...................296

Compare the size of the directory database files to the volume size

Back up system state .........................................................................................297 See Also......................................................................................................................300 Restart the domain controller in Directory Services Restore Mode locally ...........300 See Also......................................................................................................................300 Restart the domain controller in Directory Services Restore Mode Remotely ......301 See Also......................................................................................................................302 Move the directory database and log files to a local drive Copy the directory database and log files to a remote share ...................................303 ...............................306

Returning Unused Disk Space from the Active Directory Database to the File System ....................................................................................................................................308 Change the garbage collection logging level to 1 ................................................310

Back up system state .........................................................................................310 See Also......................................................................................................................313 Restart the domain controller in Directory Services Restore Mode locally ...........313 See Also......................................................................................................................314 Restart the domain controller in Directory Services Restore Mode Remotely ......314 See Also......................................................................................................................315 Compact the directory database file (offline defragmentation) .............................316 . 319

If database integrity check fails, perform semantic database analysis with fixup Administering Domain Controllers

......................................................................320

Introduction to Administering Domain Controllers ...............................................321 Installing and Removing Active Directory.....................................................................321 Renaming Domain Controllers.....................................................................................322 Adding Domain Controllers to Remote Sites................................................................322 Managing Domain Controllers ............................................................................323 Managing Antivirus Software on Domain Controllers....................................................324 Preparing for Active Directory Installation ...........................................................327 Configuring DNS.........................................................................................................328 Site Placement............................................................................................................328 Domain Connectivity....................................................................................................329

Install the DNS Server service

............................................................................330 .............................................................331 . .332

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 availability of the operations masters Installing a Domain Controller in an Existing Domain Install Active Directory

...........................................333 ..................................................334 ..........................................335

........................................................................................336

Installing a Domain Controller in an Existing Domain Using Restored Backup Media ....................................................................................................................................337 See Also......................................................................................................................340 Back up system state .........................................................................................340 See Also......................................................................................................................343 Restore system state to an alternate location .....................................................343

Install Active Directory from restored backup media ...........................................344 See Also......................................................................................................................345 Include application directory partitions in an Active Directory installation from backup media ....................................................................................................................................346 Adding Domain Controllers in Remote Sites .......................................................347

Known Issues for Adding Domain Controllers in Remote Sites ...........................348 SYSVOL Replication....................................................................................................349 Using Backup Media to Install Active Directory in a Remote Site..................................349 Installing Domain Controllers Before Shipping Them to the Remote Site.....................353 See Also......................................................................................................................357 Best Practices for Adding Domain Controllers in Remote Sites ...........................357 Using Backup Media to Install Active Directory in the Remote Site...............................357 Installing Domain Controllers Prior to Shipping to the Remote Site..............................359 See Also......................................................................................................................362 Preparing a Server Computer for Shipping and Installation from Backup Media . 363 Restore the Backup to the Promotion Computer or Ship Removable Media.................364 Determine the Restore Volume....................................................................................365 Enable Remote Desktop..............................................................................................366

Create a Domain Controller Installation Answer File....................................................366 See Also......................................................................................................................369 Back up system state .........................................................................................369 See Also......................................................................................................................371 Restore system state to an alternate location Enable Remote Desktop .....................................................371

....................................................................................373

Create an answer file for domain controller installation .......................................374 See Also......................................................................................................................377 Create a Remote Desktop Connection ...............................................................377 See Also......................................................................................................................378 Install Active Directory from restored backup media ...........................................378 See Also......................................................................................................................379 Include application directory partitions in an Active Directory installation from backup media ....................................................................................................................................379 Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection ....................................................................................................................................380 See Also......................................................................................................................382 Determine the tombstone lifetime for the forest View the current operations master role holders Transfer the domain-level operations master roles Transfer the schema master Transfer the domain naming master ..................................................382 .................................................383 .............................................384

...............................................................................385 ...................................................................386 .......................387

Prepare a domain controller for nonauthoritative SYSVOL restart Enable strict replication consistency

...................................................................389

Synchronize replication with all partners .............................................................390 See Also......................................................................................................................391 Verify successful replication to a domain controller .............................................392 See Also......................................................................................................................394 Reconnecting a Domain Controller After a Long-Term Disconnection .................394

Reconnecting an Outdated Domain Controller.............................................................395 Updating SYSVOL.......................................................................................................395 See Also......................................................................................................................397 Determine when intersite replication is scheduled to begin .................................397

Use Repadmin to remove lingering objects ........................................................398 See Also......................................................................................................................400 Verify successful replication to a domain controller .............................................400 See Also......................................................................................................................403 Performing an Unattended Installation of Active Directory ..................................403 See Also......................................................................................................................404 Create an answer file for domain controller installation .......................................404 See Also......................................................................................................................406 Install Active Directory using an answer file ........................................................406 See Also......................................................................................................................407 Verifying Active Directory Installation ..................................................................407 .........................................408 . .409

Determine whether a Server object has child objects

Verify that an IP address maps to a subnet and determine the site association Move the Server object to the new site Configure DNS server forwarders Verifying DNS configuration

...............................................................410 .......................................................................411

................................................................................411 ........................................................412

Create a delegation for a domain controller Create a secondary zone Configure the DNS client settings Check the status of the shared SYSVOL Verify DNS registration and functionality

...................................................................................413 .......................................................................413 ............................................................414 .............................................................415 ...........................................416 ...................................................417 ..................................................418

Verify communication with other domain controllers Verify replication with other domain controllers Verify the availability of the operations masters

Verify domain membership for a new domain controller Renaming a Domain Controller

......................................419

..........................................................................420

Rename a domain controller using System Properties ........................................421 See Also......................................................................................................................421 Rename a domain controller using Netdom ........................................................422 See Also......................................................................................................................423 Update the FRS member object Decommissioning a Domain Controller .........................................................................424 ...............................................................424 .................................................426

View the current operations master role holders Transfer the schema master Transfer the domain naming master

...............................................................................427 ...................................................................428 .............................................429 ......................430

Transfer the domain-level operations master roles

Determine whether a domain controller is a global catalog server Verify DNS registration and functionality

.............................................................431 ...........................................431 ..................................................432

Verify communication with other domain controllers Verify the availability of the operations masters Uninstall Active Directory

....................................................................................433 .........................................434

Determine whether a Server object has child objects Delete a Server object from a site

......................................................................435 ......................................................435

Forcing the Removal of a Domain Controller Identify replication partners Force domain controller removal Clean up server metadata

................................................................................436 ........................................................................437 ..................................................................................438 .....................................441

Additional Resources for Administering Active Directory Troubleshooting Active Directory Operations

......................................................442 .............................442

Configuring a Computer for Troubleshooting Active Directory

Configuration Tasks for Troubleshooting......................................................................443 Troubleshooting Active Directory Replication Problems ......................................446 Event and Tool Solution Recommendations.................................................................447 Ruling Out the Obvious................................................................................................447 Correct Response to Any Outdated Server Running Windows 2000 Server.................448 Root Causes................................................................................................................448 General Approach to Fixing Problems..........................................................................449 Monitoring Replication Health......................................................................................449 Attempting to Resolve Problems..................................................................................452 Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042) ......457 Tombstone Lifetime and Replication of Deletions.........................................................457 How Lingering Objects Occur......................................................................................458 Causes of Long Disconnections...................................................................................458 Indications That a Domain Controller Has Lingering Objects........................................459 Tool for Removing Lingering Objects...........................................................................462 See Also......................................................................................................................463 Event ID 1388 or 1988: A lingering object is detected .........................................463 Event ID 1388..............................................................................................................463 Event ID 1988..............................................................................................................464 Cause..........................................................................................................................465 Solution.......................................................................................................................465 A deleted account remains in the Address Book, e-mail is not received, or a duplicate account exists .................................................................................................470 Solution.......................................................................................................................471 Event ID 2042: It has been too long since this machine replicated ......................472 Solution.......................................................................................................................474 Fixing Replication Security Problems .................................................................476

An "Access denied" or other security error has caused replication problems ......477 Cause..........................................................................................................................477 Solution.......................................................................................................................477 Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) ............480 Improvements to Domain Controller Name Resolution in SP1.....................................481 DNS Requirements for CNAME Lookup Success........................................................483 Event ID 1925: Attempt to establish a replication link failed due to DNS lookup problem ....................................................................................................................................484

Solution.......................................................................................................................485 Event ID 2087: DNS lookup failure caused replication to fail ...............................485 Cause..........................................................................................................................487 Solution.......................................................................................................................488 Event ID 2088: DNS lookup failure occurred with replication success .................500 Cause..........................................................................................................................502 Solution.......................................................................................................................502 Fixing Replication Connectivity Problems (Event ID 1925) ..................................502

Event ID 1925: Attempt to establish a replication link failed due to connectivity problem ....................................................................................................................................502 Cause..........................................................................................................................503 Solution.......................................................................................................................503 Fixing Replication Topology Problems (Event ID 1311) .......................................509

Event ID 1311: Replication configuration does not reflect the physical network ...509 Cause..........................................................................................................................510 Solution.......................................................................................................................511 Additional Resources for Troubleshooting Active Directory .................................517

Active Directory Operations Guide


The Active Directory Operations Guide provides administering and troubleshooting information for Active Directory directory service technologies in the Microsoft Windows Server 2003 and Windows Server 2003 with Service Pack 1 (SP1) operating systems. You cannot install Active Directory on a server running Windows Server 2003, Web Edition, but you can join the server to an Active Directory domain as a member server. For more information about Windows Server 2003, Web Edition, see Overview of Windows Server 2003, Web Edition, on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=9253). Note The Windows Server 2003 Active Directory Operations Guide is also available as a downloadable document on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=63079). In this guide Administering Active Directory Operations Troubleshooting Active Directory Operations

Administering Active Directory Operations


This guide provides administering information for Active Directory in the Microsoft Windows Server 2003 and Windows Server 2003 with Service Pack 1 (SP1) operating systems. Information includes detailed procedures for managing domain controllers, sites, trusts, and other components of Active Directory. In this guide Introduction to Administering Active Directory New in This Guide for Administering Active Directory Administering Domain and Forest Trusts Administering the Windows Time Service

Administering SYSVOL Administering the Global Catalog Administering Operations Master Roles Administering Active Directory Backup and Restore Administering Intersite Replication Administering the Active Directory Database Administering Domain Controllers Additional Resources for Administering Active Directory

Note You cannot install Active Directory on a server running Windows Server 2003, Web Edition, but you can join the server to an Active Directory domain as a member server. For more information about Windows Server 2003, Web Edition, see Overview of Windows Server 2003, Web Edition, on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=9253). Acknowledgments Key Technical Reviewers: Chris Macaulay, Nigel Cain, Arren Conner, Dmitry Dukat, Levon Esibov, Khushru Irani, Kamal Janardhan, Gregory Johnson, William Lees, Andreas Luther, Kevin Sims, Jeromy Statia, Eric Kool-Brown, J. K. Jaganathan, Mike Resnick, Michael Snyder, Nathan Muggli, Yi Zhao, Christopher Westpoint, Robert Powalka, Rob Kochman Microsoft Most Valuable Professional (MVP) Reviewers: Joseph Shook, Thomas Bittner, Nuo Yan, Al Mulnick, Tony Murray, Guido Grillenmeier, M. Rajesh, Todd Myrick

Introduction to Administering Active Directory


This guide explains how to administer Microsoft Active Directory. These activities are part of the operating phase of the information technology (IT) life cycle. If you are not familiar with this guide, review the following sections of this introduction.

When to Use This Guide


You should use this guide when:

You want to manage common Active Directory problems that are associated with misconfiguration. You want to configure Active Directory to increase network availability.

This guide assumes a basic understanding of what Active Directory is, how it works, and why your organization uses it to access, manage, and secure shared resources across your network. You should also have a thorough understanding of how Active Directory is deployed and managed in your organization. This includes an understanding of the mechanism your organization uses to configure and manage Active Directory settings. This guide can be used by organizations that have deployed Windows Server 2003 and Windows Server 2003 with Service Pack 1 (SP1). 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 to plan an Active Directory operations environment. This information provides management-level knowledge of Active Directory and the IT processes required to operate it. In addition, this guide contains more detailed 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 administrative programs and access the command line. If operators are not familiar with Active Directory, it might be necessary for IT planners or IT managers to review the relevant operations in this guide and provide the operators with parameters or data that must be entered when the operation is performed.

How to Use this Guide


The operations areas are divided into the following types of content: Objectives are high-level goals for managing, monitoring, optimizing, and securing Active Directory. Each objective consists of one or more high-level tasks that describe how the objective is accomplished. Tasks are used to group related procedures and provide general guidance for achieving the goals of an objective. Procedures provide step-by-step instructions for completing the task.

If you are an IT manager who will be delegating tasks to operators within your organization, you will want to:

Read through the objectives and tasks to determine how to delegate permissions and whether you need to install tools before operators perform the procedures for each task. Before assigning tasks to individual operators, ensure that you have all the tools installed where operators can use them. When necessary, 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.

New in This Guide for Administering Active Directory


This operations guide is updated periodically to incorporate new content, customer feedback, and corrections. The following sections provide details about content that is new or updated in this version of the guide.

New Content
August 2005: Performing an Authoritative Restore of Active Directory Objects contains new procedures for regenerating the group memberships of restored user objects and group objects. This functionality is available in the version of Ntdsutil.exe that is included with Windows Server 2003 with Service Pack 1 (SP1). February 2006: Enable Remote Desktop contains a new procedure to enable Remote Desktop remotely by using the registry. February 2006: Known Issues for Adding Domain Controllers in Remote Sites contains the additional information that moving the Ntds.dit file takes less time than copying the file when you restore a system state backup.

Updated Content
April 2006: Performing an Authoritative Restore of Active Directory Objects contains corrected information about the details of updating back-link attributes.

Administering Domain and Forest Trusts


This guide provides administrators with step-by-step instructions for managing and securing Windows Server 2003 domain and forest trusts. The way that you create or configure trusts plays an important role in operating and securing your network infrastructure. How you create or configure domain and forest trusts in Windows Server 2003 also determines how far network communications extend within a forest or across forests. Note You cannot install Active Directory on a server running Windows Server 2003, Web Edition, but you can join the server to an Active Directory domain as a member server. For more information about Windows Server 2003, Web Edition, see Overview of Windows Server 2003, Web Edition, on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=9253). In this guide Introduction to Domain and Forest Trusts Best Practices for Domain and Forest Trusts Managing Domain and Forest Trusts Securing Domain and Forest Trusts Appendix: New Trust Wizard Pages

Acknowledgements Produced by: Microsoft Windows Server Security and Directory Services User Assistance team Project Writer: Nick Pierson Project Editor: Jim Becker

Introduction to Domain and Forest Trusts


By using Windows Server 2003 domain and forest trusts, service administrators can create or extend collaborative relationships between two or more domains or forests. Windows Server 2003 domains and forests can also trust Kerberos realms and other Windows Server 2003 forests, as well as Microsoft Windows 2000 domains and Windows NT 4.0 domains.

When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help to provide controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only validated authentication requests to travel between domains. How a specific trust passes authentication requests depends on how it is configured. Trust relationships can be one-way, providing access from the trusted domain to resources in the trusting domain, or two-way, providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case a trust exists only between the two trust partner domains, or transitive, in which case a trust automatically extends to any other domains that either of the partners trusts. In some cases, trust relationships are established automatically when domains are created; in other cases, administrators must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts that are used and the structure of the resulting trust relationships in a given trust implementation depend on such factors as how Active Directory is organized and whether different versions of Windows coexist on the network.

Best Practices for Domain and Forest Trusts


The following best practices are proven to increase availability, ensure trouble-free operations, or ease administration when you use them to administer domain and forest trusts: When your forest contains domain trees with many child domains and you observe noticeable user authentication delays between the child domains, you can optimize the user authentication process between the child domains by creating shortcut trusts to mid-level domains in the domain tree hierarchy. For more information, see When to create a shortcut trust on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42644). Keep a current list of trust relationships for future reference. You can use the Nltest.exe tool to display and record a list of these trusts. For more information, see "Nltest.exe: NLTest Overview" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42642).

Perform regular backups of domain controllers to preserve all trust relationships within a particular domain. For more information, see Back up system state.

Managing Domain and Forest Trusts


It is necessary to manage domain and forest trusts when your organization needs to collaborate with users or resources that are located in other domains, realms, or forests in your organization and in other organizations. To set up an environment that takes advantage of trusts, you must first create and configure the appropriate trusts that will enable your organization to communicate effectively with users or resources in other places. The following objectives are part of managing domain and forest trusts: Creating Domain and Forest Trusts Configuring Domain and Forest Trusts

Creating Domain and Forest Trusts


In Windows Server 2003, there are four trust types that must be created manually. External trusts, realm trusts, and forest trusts help provide interoperability with domains outside your forest or with realms. Shortcut trusts optimize access to resources and logons that are made between domain trees in the same forest. The following tasks for creating domain and forest trusts are described in this objective: Creating External Trusts Creating Shortcut Trusts Creating Forest Trusts Creating Realm Trusts Note A trust does not inherently allow users in a trusted domain to have access to resources in a trusting domain. Users have access when they are assigned the appropriate permissions. In some cases, users in trusted domains may have implicit access if the resources are assigned to Authenticated Users.

New Trust Wizard Terminology


You create trusts in Windows Server 2003 with the New Trust Wizard. Before you use the New Trust Wizard, review the following terminology. Each highlighted term represents the exact term as it is used in the wizard: This domain: The domain from which you launch the New Trust Wizard. When you start the wizard, it immediately verifies your administrative credentials in the domain for which you are the administrator. Therefore, the wizard uses the term this domain to represent the domain that you are currently logged on to. Local domain / Local forest: The domain or forest where you start the New Trust Wizard. Specified domain / Specified forest: The other domain or forest that this local domain or local forest will trust. Although the New Trust Wizard is aware of the domain context in which it is running, it does not have knowledge of the other domain that you want to create the relationship with. After you type the name of the other domain or forest in the Trust Name page, that name is used whenever the wizard refers to the specified domain or specified forest. Two-way trust: A trust relationship between two domains in which both domains trust each other. For example, domain A trusts domain B, and domain B trusts domain A. All parent-child trusts are two-way trusts. One-way: incoming trust: A one-way trust relationship between two domains in which the direction of the trust points toward the domain from which you start the New Trust Wizard (and which is identified in the wizard as This domain). When the direction of the trust points toward your domain, users in your domain can access resources in the specified domain. For example, if you are the domain administrator in domain A and you create a one-way, incoming trust to domain B, this provides a relationship through which users who are located in domain A can access resources in domain B. Because this relationship is one-way, users in domain B cannot access resources in domain A. One-way: outgoing trust: A one-way trust relationship between two domains in which the direction of the trust points toward the domain that is identified as Specified domain in the New Trust Wizard. When the direction of trust points toward the specified domain, users in the specified domain can access resources in your domain. For example, if you are the domain administrator in domain A and you create a oneway, outgoing trust to domain B, this provides a relationship through which users who are located in domain B can access resources in domain A. Because this relationship is one way, users in domain A cannot access resources in domain B.

Both sides of the trust: When you create external trusts, shortcut trusts, or forest trusts, you have the option to create each side of the trust separately or both sides of the trust simultaneously. If you choose to create each side of the trust separately, you must run the New Trust Wizard twice once for each domain. When you create trusts separately, you must supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords. Domain-wide authentication: An authentication setting that permits unrestricted access by any users in the specified domain to all available shared resources that are located in the local domain. This is the default authentication setting for external trusts. Forest-wide authentication: An authentication setting that permits unrestricted access by any users in the specified forest to all available shared resources that are located in any of the domains in the local forest. This is the default authentication setting for forest trusts. Selective authentication: An authentication setting that restricts access over an external trust or forest trust to only those users in a specified domain or specified forest who have been explicitly given authentication permissions to computer objects (resource computers) that reside in the local domain or the local forest. This authentication setting must be enabled manually. Trust password: An option in which both domains in a trust relationship share a password, which is stored in the trusted domain object (TDO) object in Active Directory. When you choose this option, a strong trust password is generated automatically for you. You must use the same password when you create a trust relationship in the specified domain. If you choose to create both sides of the trust simultaneously, you run the New Trust Wizard once.

Known Issues for Creating Domain and Forest Trusts


Review the following known issues before creating domain and forest trusts in Windows Server 2003: You cannot delegate the creation of trusts to any user who is not a member of the Domain Admins or Enterprise Admins groups. Even though you can grant a user the Create TDO (Trusted Domain Object) right or the Delete TDO right in the System container of a domain, the user will not be granted the right to create a trust. This issue occurs because Netlogon and the trust-creation tools (Active Directory Domains and Trusts and Netdom) are designed so that only members of the Domain Admins group

and the Enterprise Admins group can create trusts. However, any user who is a member of the Incoming Forest Trust Builders group can create one-way, incoming forest trusts to your forest. For more information about the Incoming Forest Trust Builders group, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). When you are logged on locally to a domain controller and you try to create a new trust by using Active Directory Domains and Trusts, the operation may be unsuccessful and you may receive the message Access denied. This issue occurs only if you are logged on locally to the domain controller as an ordinary user (meaning that the user is not logged on as Administrator or as a member of any administrative groups for the domain). By default, ordinary users are blocked from logging on locally to a domain controller unless Group Policy is modified to permit this. When you use Active Directory Domains and Trusts to create a trust, you may receive the message Operation failed. Parameter incorrect. This issue may occur if you try to establish a trust relationship when the source domain and the target domain have one or more of the following identifiers that are the same: Security identifier (SID) Domain Name System (DNS) name Network basic input/output system (NetBIOS) name

To resolve this issue, do one of the following before you try to create the trust, as appropriate to your situation: Rename the conflicting identifier. Use a fully qualified domain name (FQDN) if there is a NetBIOS conflict.

The option to create a forest trust does not appear in the New Trust Wizard. This issue typically occurs when one or both of the Windows Server 2003 forests are not set to the Windows Server 2003 forest functional level. For more information about forest functional levels, see Active Directory Functional Levels Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41698). There are restrictions in the number and types of trusts that can be created when you target a Microsoft Windows Small Business Server 2003 domain.

Creating External Trusts


You can create an external trust to form a one-way or two-way, nontransitive trust with domains that are outside your forest. External trusts are sometimes necessary when users need access to resources that are located in a Windows NT 4.0 domain or in a domain that is in a separate Active Directory forest that is not joined by a forest trust. For example, if you have a Windows Server 2003based domain whose users want to gain access to resources that are stored in a Windows NTbased domain, you must create a trust relationship in which the Windows NTbased domain trusts the users from the Windows Server 2003based domain. In this case, the Windows NTbased domain is the trusting domain, and the Windows Server 2003based domain is the trusted domain. For more information about external trusts, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). Note Trusts that are created between Windows NT 4.0 domains and Active Directory domains are one-way and nontransitive, and they require network basic input/output system (NetBIOS) name resolution. Task requirements You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to create an external trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=41700). Note If you have the appropriate administrative credentials for each domain, you can create both sides of an external trust at the same time. To create both sides of the trust, simultaneously, follow the appropriate procedure below that contains the words both sides of the trust in the procedure title. For example, the procedure Create a one-way, incoming, external trust for both sides of the trust provides the steps to follow when you have the administrative credentials for both domains and you want to use the New Trust Wizard to create an incoming, external trust in one

operation. For more information about how the both sides of the trust option works, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. You can create an external trust by using any of the following procedures, depending on the requirements of your organization and the administrative credentials that you have when you create the trust: Create a one-way, incoming, external trust for one side of the trust Create a one-way, incoming, external trust for both sides of the trust Create a one-way, outgoing, external trust for one side of the trust Create a one-way, outgoing, external trust for both sides of the trust Create a two-way, external trust for one side of the trust Create a two-way, external trust for both sides of the trust

Create a one-way, incoming, external trust for one side of the trust
This procedure creates one side of a one-way, incoming, external trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal domain uses his or her credentials to create the second side of the trust. If you have administrative credentials for both domains that are involved in the trust, you can use the procedure Create a one-way, incoming, external trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A one-way, incoming, external trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to access resources in another Active Directory domain (outside your forest) or in a Windows NT 4.0 domain. For example, if you are the administrator of sales.wingtiptoys.com and users in that domain need to access resources in the marketing.tailspintoys.com domain (which is located in another forest), you can use this procedure (in conjunction with another procedure, which is executed by the administrator in the other forest) to establish one side of the relationship so that users in your domain can access resources in the marketing.tailspintoys.com domain. You can create this external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create an external trust, see

"Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, incoming, external trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: incoming, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. With the administrator of the other domain, agree on a secure channel password to be used in establishing the trust. 9. On the Trust Selections Completepage, review the results, and then click Next. 10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the

incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 12. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the domain administrator for the specified domain or specified forest must follow the procedure Create a one-way, outgoing, external trust for one side of the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a one-way, incoming, external trust for both sides of the trust
This procedure creates both sides of a one-way, incoming, external trust, and it requires you to have administrative credentials for your domain as well for the reciprocal domain. If you have administrative credentials only for your domain, you can use the procedure Create a one-way, incoming, external trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal domain create a one-way, outgoing, external trust from his or her domain. A one-way, incoming, external trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to access resources in another Active Directory domain (outside your forest) or in a Windows NT 4.0 domain. For example, if you are the administrator of sales.wingtiptoys.com and users in that domain need to access resources in the marketing.tailspintoys.com domain (which is located in another forest) you can use this procedure to establish a relationship so that users in your domain can access resources in the marketing.tailspintoys.com domain. You can create this external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create an external trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To create a one-way, incoming, external trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: incoming, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Outgoing Trust Authentication Level--Specified Domain page, do one of the following, and then click Next: Click Domain-wide authentication. Click Selective authentication.

10. On the Trust Selections Complete page, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified

domain. 13. On the Completing the New Trust Wizard page, click Finish.

Create a one-way, outgoing, external trust for one side of the trust
This procedure creates one side of a one-way, outgoing, external trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal domain uses his or her credentials to create the second side of the trust. If you have administrative credentials for both domains that are involved in the trust, you can use the procedure Create a one-way, outgoing, external trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A one-way, outgoing, external trust will allow resources in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to be accessed by users in a different Active Directory domain (outside your forest) or in a Windows NT 4.0 domain. For example, if you are the administrator of sales.wingtiptoys.com and you have resources in that domain that need to be accessed by users in the marketing.tailspintoys.com domain (which is located in another forest), you can use this procedure to establish one side of the relationship so that users in the marketing.tailspintoys.com domain can access the resources in sales.wingtiptoys.com. You can create this external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create an external trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, outgoing, external trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties.

3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: outgoing, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Outgoing Trust Authentication Level page, do one of the following, and then click Next: Click Domain-wide authentication. Click Selective authentication.

9. On the Trust Password page, type the trust password twice, and then click Next. 10. On the Trust Selections Completepage, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 13. On the Completing the New Trust Wizard page, click Finish.

Note For this trust to function, the domain administrator for the specified domain or specified forest must follow the procedure Create a one-way, incoming, external trust for one side of the trust, using his or her administrative credentials and the exact same trust passwordthat was used during this procedure.

Create a one-way, outgoing, external trust for both sides of the trust
This procedure creates both sides of a one-way, outgoing, external trust, and it requires you to have administrative credentials for your domain as well as for the reciprocal domain. If you have administrative credentials only for your domain, you can use the procedure Create a one-way, outgoing, external trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal domain create a one-way, incoming, external trust from his or her domain. A one-way, outgoing, external trust allows resources in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to be accessed by users in a different Active Directory domain (outside your forest) or in a Windows NT 4.0 domain. For example, if you are the administrator of sales.wingtiptoys.com and you have resources in that domain that need to be accessed by users in the marketing.tailspintoys.com domain (which is located in another forest), you can use this procedure to establish one side of the relationship so that users in the marketing.tailspintoys.com domain can access the resources in sales.wingtiptoys.com. You can create this external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create an external trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, outgoing, external trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust

with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: outgoing, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Outgoing Trust Authentication Level--Local Domain page, do one of the following, and then click Next: Click Domain-wide authentication. Click Selective authentication.

10. On the Trust Selections Complete page, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain.

13. On the Completing the New Trust Wizard page, click Finish.

Create a two-way, external trust for one side of the trust


This procedure creates one side of a two-way, external trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal domain uses his or her credentials to create the second side of the trust. If you have administrative credentials for both domains that are involved in the trust, you can use the procedure Create a two-way, external trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A two-way, external trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) and users in the reciprocal domain to access resources in either of the two domains. You can create this external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create an external trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a two-way, external trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next.

6. On the Direction of Trust page, click Two-way, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Outgoing Trust Authentication Level page, do one of the following, and then click Next: Click Domain-wide authentication. Click Selective authentication.

9. On the Trust Password page, type the trust password twice, and then click Next. 10. On the Trust Selections Completepage, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 13. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 14. On the Completing the New Trust Wizard page, click Finish.

Note For this trust to function, the domain administrator for the specified domain or specified forest must follow this same procedure, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a two-way, external trust for both sides of the trust


This procedure creates both sides of a two-way, external trust, and it requires you to have administrative credentials for your domain as well as for the reciprocal domain. If you have administrative credentials only for your domain, you can use the procedure Create a twoway, external trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal domain create a one-way, outgoing, external trust from his or her domain. A two-way, external trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) and users in the reciprocal domain to access resources in either of the two domains. You can create this external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create an external trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a two-way, external trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click

Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click Two-way, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Outgoing Trust Authentication Level--Local Domain page, do one of the following, and then click Next: Click Domain-wide authentication. Click Selective authentication.

10. On the Outgoing Trust Authentication Level--Specified Domain page, do one of the following, and then click Next: Click Domain-wide authentication. Click Selective authentication.

11. On the Trust Selections Complete page, review the results, and then click Next. 12. On the Trust Creation Complete page, review the results, and then click Next. 13. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 14. On the Confirm Incoming Trust page, do one of the following:

If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 15. On the Completing the New Trust Wizard page, click Finish.

Creating Shortcut Trusts


A shortcut trust is a manually created trust that shortens the trust path to improve the speed at which authentications, which are made between domain trees, are processed. This can result in faster logon times and faster access to resources. 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. For more information about shortcut trusts, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). Task requirements You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to create a shortcut trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Note If you have the appropriate administrative credentials for each domain, you can create both sides of a shortcut trust at the same time. To create both sides of the trust, follow the appropriate procedure below that contains the words for both sides of the trust in the title. For example, the procedure Create a one-way, incoming, shortcut trust for both sides of the trust explains how to configure both sides of a shortcut trust. For more information about how the both sides of the

trust option works, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. You can create a shortcut trust by using any of the following procedures, depending on the requirements of your organization and the administrative credentials that you have when you create the trust: Create a one-way, incoming, shortcut trust for one side of the trust Create a one-way, incoming, shortcut trust for both sides of the trust Create a one-way, outgoing, shortcut trust for one side of the trust Create a one-way, outgoing, shortcut trust for both sides of the trust Create a two-way, shortcut trust for one side of the trust Create a two-way, shortcut trust for both sides of the trust

Create a one-way, incoming, shortcut trust for one side of the trust
This procedure creates one side of a one-way, incoming, shortcut trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal domain uses his or her credentials to create the second side of the trust. If you have administrative credentials for both domains that are involved in the trust, you can use the procedure Create a one-way, incoming, shortcut trust for both sides of the trust to create both sides in one simultaneous operation. A one-way, incoming, shortcut trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to more quickly access resources in another domain (which is nested within another domain tree) in your forest. For example, if you are the administrator of sales.wingtiptoys.com and users in that domain need to access resources in the marketing.tailspintoys.com domain (which is a child domain of the tailspintoys.com tree root domain), you can use this procedure to establish one side of the relationship so that users in your domain can more quickly access resources in the marketing.tailspintoys.com domain. You can create this shortcut trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a shortcut trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700).

Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, incoming, shortcut trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: incoming, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. 9. On the Trust Selections Complete page, review the results, and then click Next. 10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain.

12. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the domain administrator for the specified domain or specified forest must follow the procedure Create a one-way, outgoing, shortcut trust for one side of the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a one-way, incoming, shortcut trust for both sides of the trust
This procedure creates both sides of a one-way, incoming, shortcut trust, and it requires you to have administrative credentials for your domain as well for the reciprocal domain. If you have administrative credentials only for your domain, you can use the procedure Create a one-way, incoming, shortcut trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal domain create a one-way, outgoing, shortcut trust from his or her domain. A one-way, incoming, shortcut trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to more quickly access resources in another domain (which is nested within another domain tree) in your forest. For example, if you are the administrator of sales.wingtiptoys.com and users in that domain need to access resources in the marketing.tailspintoys.com domain (which is a child domain of the tailspintoys.com tree root domain), you can use this procedure to establish one side of the relationship so that users in your domain can more quickly access resources in the marketing.tailspintoys.com domain. You can create this shortcut trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a shortcut trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, incoming, shortcut trust for both sides of the trust 1. Open Active Directory Domains and Trusts.

2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: incoming, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Trust Selections Complete page, review the results, and then click Next. 10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 12. On the Completing the New Trust Wizard page, click Finish.

Create a one-way, outgoing, shortcut trust for one side of the trust
This procedure creates one side of a one-way, outgoing, shortcut trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal domain uses his or her credentials to create the second side of the trust. If you have administrative credentials for both domains that are involved in the trust, you can use the procedure Create a one-way, outgoing, shortcut trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A one-way, outgoing, shortcut trust allows resources in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to be accessed more quickly by users in another domain (which is nested within another domain tree) in your forest. For example, if you are the administrator of marketing.tailspintoys.com and resources in that domain need to be accessed by users in the sales.wingtiptoys.com domain (which is a child domain of the wingtiptoys.com tree root domain), you can use this procedure to establish one side of the relationship so that users in the sales.wingtiptoys.com domain can more quickly access resources in the marketing.tailspintoys.com domain. You can create this shortcut trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a shortcut trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, outgoing, shortcut trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next.

5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: outgoing, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. 9. On the Trust Selections Complete page, review the results, and then click Next. 10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 12. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the domain administrator for the specified domain or specified forest must follow the procedure Create a one-way, incoming, shortcut trust for one side of the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a one-way, outgoing, shortcut trust for both sides of the trust
This procedure creates both sides of a one-way, outgoing, shortcut trust, and it requires that you have administrative credentials for your domain as well as for the reciprocal domain. If you have administrative credentials only for your domain, you can use the procedure Create a one-way, outgoing, shortcut trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal domain create a one-way, incoming, shortcut trust from his or her domain. A one-way, outgoing, shortcut trust allows resources in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to be accessed more quickly by users in another domain (which is nested within another domain tree) in your forest. For example, if you are the administrator of marketing.tailspintoys.com and resources in that domain need to be accessed by users in the sales.wingtiptoys.com domain (which is a child domain of the wingtiptoys.com tree root domain), you can use this procedure to establish one side of the relationship so that users in the sales.wingtiptoys.com domain can more quickly access resources in the marketing.tailspintoys.com domain. You can create this shortcut trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a shortcut trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, outgoing, shortcut trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next.

5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click One-way: outgoing, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Trust Selections Complete page, review the results, and then click Next. 10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 12. On the Completing the New Trust Wizard page, click Finish.

Create a two-way, shortcut trust for one side of the trust


This procedure creates one side of a two-way, shortcut trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal domain uses his or her credentials to create the second side of the trust. If you

have administrative credentials for both domains that are involved in the trust, you can use the procedure Create a two-way, shortcut trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A two-way, shortcut trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) and users in the reciprocal domain to more quickly access resources in either domain (when both domains are separated by a domain tree) in your forest. You can create this shortcut trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a shortcut trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a two-way, shortcut trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click Two-way, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next.

9. On the Trust Selections Completepage, review the results, and then click Next. 10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 12. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 13. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the domain administrator for the specified domain must follow this same procedure using his or her administrative credentials and the exact same trust passwordthat was used during this procedure.

Create a two-way, shortcut trust for both sides of the trust


This procedure creates both sides of a two-way, shortcut trust, and it requires you to have administrative credentials for your domain as well as for the reciprocal domain. If you have administrative credentials only for your domain, you can use the procedure Create a twoway, shortcut trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal domain create a two-way, shortcut trust from his or her domain.

A two-way, shortcut trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) and users in the reciprocal domain to more quickly access resources in either domain (when both domains are separated by a domain tree) in your forest. You can create this shortcut trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a shortcut trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a two-way, shortcut trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 6. On the Direction of Trust page, click Two-way, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Trust Selections Completepage, review the results, and then click Next.

10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 12. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 13. On the Completing the New Trust Wizard page, click Finish.

Creating Forest Trusts


In a Windows Server 2003 forest, you can link two disjoined Windows Server 2003 forests together to form a one-way or two-way, transitive trust relationship. You can use a two-way, forest trust to form a transitive trust relationship between every domain in both forests. For more information about forest trusts, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). Task requirements The following requirements, features, or settings are necessary to create forest trusts successfully: You can create a forest trust only between two Windows Server 2003 forests; forest trusts cannot be extended implicitly to a third Windows Server 2003 forest.

To create a forest trust, you must set the forest functional level for both of the Windows Server 2003 forests that are involved in the trust relationship to Windows Server 2003. For more information about functional levels, see Active Directory Functional Levels Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41698). To create a forest trust successfully, you must set up your Domain Name System (DNS) environment properly. If there is a root DNS server that you can make the root DNS server for the DNS namespaces of both forests, make it the root server by ensuring that the root zone contains delegations for each of the DNS namespaces. Also, update the root hints of all DNS servers with the new root DNS server. If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are running a member of the Windows Server 2003 family, configure DNS conditional forwarders in each DNS namespace to route queries for names in the other namespace. If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are not running a member of the Windows Server 2003 family, configure DNS secondary zones in each DNS namespace to route queries for names in the other namespace. For more information about configuring DNS to work with Active Directory, see DNS Support for Active Directory Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41699). You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to create a forest trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Note If you have the appropriate administrative credentials for each forest, you can create both sides of a forest trust at the same time. To create both sides of the forest trust, follow the appropriate procedure below that contains the words for both sides of the trust in the title. For example, the procedure Create a one-way, incoming, forest trust for both sides of the trust explains how to configure both sides of the trust. For more information about how the both sides of the trust option works, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages.

You can create a forest trust by using any one of the following procedures, depending on the requirements of your organization and the administrative credentials that you have when you create the trust: Create a one-way, incoming, forest trust for one side of the trust Create a one-way, incoming, forest trust for both sides of the trust Create a one-way, outgoing, forest trust for one side of the trust Create a one-way, outgoing, forest trust for both sides of the trust Create a two-way, forest trust for one side of the trust Create a two-way, forest trust for both sides of the trust

Create a one-way, incoming, forest trust for one side of the trust
This procedure creates one side of a one-way, incoming, forest trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal forest uses his or her credentials to create the second side of the trust. If you have administrative credentials for both forests that are involved in the trust, you can use the procedure Create a one-way, incoming, forest trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A one-way, incoming, forest trust allows users in your Windows Server 2003 forest (the forest that you are logged on to at the time that you run the New Trust Wizard) to access resources in another Windows Server 2003 forest. For example, if you are the administrator of the wingtiptoys.com forest and users in that forest need to access resources in the tailspintoys.com forest, you can use this procedure to establish one side of the relationship so that users in your forest can access resources in any of the domains that make up the tailspintoys.com forest. You can create this forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a forest trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. If you are a member

of the Incoming Forest Trust Builders group, you can create one-way, incoming, forest trusts to your forest. For more information about the Incoming Forest Trust Builders group, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). To create a one-way, incoming, forest trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Forest trust, and then click Next. 6. On the Direction of Trust page, click One-way: incoming, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. 9. On the Trust Selections Complete page, review the results, and then click Next. 10. On the Trust Creation Complete page, review the results, and then click Next. 11. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain.

12. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the domain administrator for the specified domain (the forest root domain in the specified forest) must complete the procedure Create a one-way, outgoing, forest trust for one side of the trust, using their administrative credentials and the exact same trust passwordthat was used during this procedure.

Create a one-way, incoming, forest trust for both sides of the trust
This procedure creates both sides of a one-way, incoming, forest trust, and it requires you to have administrative credentials for your forest as well as for the reciprocal forest. If you have administrative credentials only for your forest, you can use the procedure Create a one-way, incoming, forest trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal forest create a one-way, outgoing forest trust from his or her domain. A one-way, incoming, forest trust allows users in your Windows Server 2003 forest (the forest that you are logged on to at the time that you run the New Trust Wizard) to access resources in another Windows Server 2003 forest. For example, if you are the administrator of the wingtiptoys.com forest and users in that forest need to access resources in the tailspintoys.com forest, you can use this procedure to establish one side of the relationship so that users in your forest can access resources in any of the domains that make up the tailspintoys.com forest. You can create this forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a forest trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming, forest trusts to your forest. For more information about the Incoming Forest Trust Builders group,

see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). To create a one-way, incoming, forest trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Forest trust, and then click Next. 6. On the Direction of Trust page, click One-way: incoming, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Outgoing Trust Authentication Level--Specified Forest page, do one of the following, and then click Next: Click Forest-wide authentication. Click Selective authentication.

10. On the Trust Selections Complete page, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the

incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 13. On the Completing the New Trust Wizard page, click Finish.

Create a one-way, outgoing, forest trust for one side of the trust
This procedure creates one side of a one-way, outgoing, forest trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal forest uses his or her credentials to create the second side of the trust. If you have administrative credentials for both forests that are involved in the trust, you can use the procedure Create a one-way, outgoing, forest trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A one-way, outgoing, forest trust allows resources in your Windows Server 2003 forest (the forest that you are logged on to at the time that you run the New Trust Wizard) to be accessed by users in another Windows Server 2003 forest. For example, if you are the administrator of the wingtiptoys.com forest and resources in that forest need to be accessed by users in the tailspintoys.com forest, you can use this procedure to establish one side of the relationship so that users in the tailspintoys.com forest can access resources in any of the domains that make up the wingtiptoys.com forest. You can create this forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a forest trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming, forest trusts to your forest. For more information about the Incoming Forest Trust Builders group, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356).

To create a one-way, outgoing, forest trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Forest trust, and then click Next. 6. On the Direction of Trust page, click One-way: outgoing, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Outgoing Trust Authentication Level page, do one of the following, and then click Next: Click Forest-wide authentication. Click Selective authentication.

9. On the Trust Password page, type the trust password twice, and then click Next. 10. On the Trust Selections Complete page, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust,

and then supply the appropriate administrative credentials from the specified domain. 13. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the domain administrator for the specified domain (the forest root domain in the specified forest) must follow the procedure Create a oneway, incoming, forest trust for one side of the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a one-way, outgoing, forest trust for both sides of the trust
This procedure creates both sides of a one-way, outgoing, forest trust, and it requires you to have administrative credentials for your forest as well as for the reciprocal forest. If you have administrative credentials only for your domain, you can use the procedure Create a one-way, outgoing, forest trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal forest create a one-way, incoming, external trust from his or her forest. A one-way, outgoing, forest trust allows resources in your Windows Server 2003 forest (the forest that you are logged on to at the time that you run the New Trust Wizard) to be accessed by users in another Windows Server 2003 forest. For example, if you are the administrator of the wingtiptoys.com forest and resources in that forest need to be accessed by users in the tailspintoys.com forest, you can use this procedure to establish one side of the relationship so that users in the tailspintoys.com forest can access resources in any of the domains that make up the wingtiptoys.com forest. You can create this forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a forest trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming, forest

trusts to your forest. For more information about the Incoming Forest Trust Builders group, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). To create a one-way, outgoing, forest trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Forest trust, and then click Next. 6. On the Direction of Trust page, click One-way: outgoing, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Outgoing Trust Authentication Level--Local Forest page, do one of the following, and then click Next: Click Forest-wide authentication. Click Selective authentication.

10. On the Trust Selections Completepage, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Outgoing Trust page, do one of the following:

If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 13. On the Completing the New Trust Wizard page, click Finish.

Create a two-way, forest trust for one side of the trust


This procedure creates one side of a two-way, forest trust. Although one side of a trust will be created successfully, the new trust will not function until the administrator for the reciprocal forest uses his or her credentials to create the second side of the trust. If you have administrative credentials for both forests that are involved in the trust, you can use the procedure Create a two-way, forest trust for both sides of the trust to create both sides of the trust in one simultaneous operation. A two-way, forest trust allows users in your forest (the forest that you are logged on to at the time that you run the New Trust Wizard) and users in the reciprocal forest to access resources in any of the domains in either of the two forests. You can create this forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a forest trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming, forest trusts to your forest. For more information about the Incoming Forest Trust Builders group, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356).

To create a two-way, forest trust for one side of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Forest trust, and then click Next. 6. On the Direction of Trust page, click Two-way, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click This domain only, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Outgoing Trust Authentication Level page, do one of the following, and then click Next: Click Forest-wide authentication. Click Selective authentication.

9. On the Trust Password page, type the trust password twice, and then click Next. 10. On the Trust Selections Completepage, review the results, and then click Next. 11. On the Trust Creation Complete page, review the results, and then click Next. 12. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified

domain. 13. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 14. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the domain administrator in the specified forest must follow this same procedure, using his or her administrative credentials and the exact same trust passwordthat was used during this procedure.

Create a two-way, forest trust for both sides of the trust


This procedure creates both sides of a two-way, forest trust, and it requires you to have administrative credentials for your forest as well as for the reciprocal forest. If you have administrative credentials only for your forest, you can use the procedure Create a twoway, forest trust for one side of the trust to create your side of the trust. Then, have the administrator for the reciprocal forest create a one-way, outgoing forest trust from his or her forest. A two-way, forest trust allows users in your forest (the forest that you are logged on to at the time that you run the New Trust Wizard) and users in the reciprocal forest to access resources in any of the domains in either of the two forests. You can create this forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a forest trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming, forest

trusts to your forest. For more information about the Incoming Forest Trust Builders group, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). To create a two-way, forest trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Forest trust, and then click Next. 6. On the Direction of Trust page, click Two-way, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 7. On the Sides of Trust page, click Both this domain and the specified domain, and then click Next. For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the User Name and Password page, type the user name and password for the appropriate administrator in the specified domain. 9. On the Outgoing Trust Authentication Level--Local Forest page, do one of the following, and then click Next: Click Forest-wide authentication. Click Selective authentication.

10. On the Outgoing Trust Authentication Level--Specified Forest page, do one of the following, and then click Next: Click Forest-wide authentication. Click Selective authentication.

11. On the Trust Selections Complete page, review the results, and then click Next.

12. On the Trust Creation Complete page, review the results, and then click Next. 13. On the Confirm Outgoing Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time the trust is used by users. If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain. 14. On the Confirm Incoming Trust page, do one of the following: If you do not want to confirm this trust, click No, do not confirm the incoming trust. If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain. 15. On the Completing the New Trust Wizard page, click Finish.

Creating Realm Trusts


You can create a realm trust to form a one-way or two-way, nontransitive or transitive trust with non-Windows Kerberos realms in your organization. You can create the trust when you log on to the domain, or you can use the Run as command to create the trust for a different domain. For more information about realm trusts, see "How Domain and Forest Trusts Work" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35356). Task requirements You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to create a realm trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Note The New Trust Wizard in Active Directory Domains and Trusts does not support the creation of both sides of a realm trust at the same time. For more information about how the both sides of the trust option works, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages. You can create a realm trust by using any of the following procedures, depending on the requirements of your organization and the administrative credentials that you have when you create the trust: Create a one-way, incoming, realm trust Create a one-way, outgoing, realm trust Create a two-way, realm trust

Create a one-way, incoming, realm trust


A one-way, incoming realm trust allows users in your Windows Server 2003 domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to access resources in the Kerberos realm. For example, if you are the administrator of the sales.wingtiptoys.com domain and users in that domain need to access resources in the Kerberos realm, you can use this procedure to establish a relationship so that users in the sales.wingtiptoys.com domain can access resources in the Kerberos realm. You can create this realm trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a realm trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, incoming, realm trust 1. Open Active Directory Domains and Trusts.

2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Realm trust, and then click Next. 6. On the Transitivity of Trust page, do one of the following: To form a trust relationship with the domain and the specified realm only, click Nontransitive, and then click Next. To form a trust relationship with the domain and the specified realm and all trusted realms, click Transitive, and then click Next. 7. On the Direction of Trust page, click One-way: incoming, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. 9. On the Trust Selections Complete page, review the results, and then click Next. 10. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the administrator of the realm must complete the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a one-way, outgoing, realm trust


A one-way, outgoing realm trust allows resources in your Windows Server 2003 domain (the domain that you are logged on to at the time that you run the New Trust Wizard) to be accessed by users in the Kerberos realm. For example, if you are the administrator of the sales.wingtiptoys.com domain and resources in that domain need to be accessed by users

in the Kerberos realm, you can use this procedure to establish a relationship so that users in the Kerberos realm can access resources in the sales.wingtiptoys.com domain. You can create this realm trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a realm trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a one-way, outgoing, realm trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Realm trust, and then click Next. 6. On the Transitivity of Trust page, do one of the following: To form a trust relationship with the domain and the specified realm only, click Nontransitive, and then click Next. To form a trust relationship with the domain and the specified realm and all trusted realms, click Transitive, and then click Next. 7. On the Direction of Trust page, click One-way: outgoing, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. 9. On the Trust Selections Complete page, review the results, and then click Next.

10. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the administrator of the realm must complete the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a two-way, realm trust


A two-way, realm trust allows users in your domain (the domain that you are logged on to at the time that you run the New Trust Wizard) and users in the specified Kerberos realm to access resources in either the domain or the Kerberos realm. You can create this realm trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a realm trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To create a two-way, realm trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties. 3. On the Trusts tab, click New Trust, and then click Next. 4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next. 5. On the Trust Type page, click Realm trust, and then click Next. 6. On the Transitivity of Trust page, do one of the following: To form a trust relationship with the domain and the specified realm only, click Nontransitive, and then click Next. To form a trust relationship with the domain and the specified realm and all

trusted realms, click Transitive, and then click Next. 7. On the Direction of Trust page, click Two-way, and then click Next. For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. 9. On the Trust Selections Complete page, review the results, and then click Next. 10. On the Completing the New Trust Wizard page, click Finish. Note For this trust to function, the administrator of the realm must complete the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

Configuring Domain and Forest Trusts


You can remove manually created trusts, but you cannot remove the default, two-way, transitive trusts between domains in a forest. If you remove manually created trusts, it is particularly important to verify that you successfully removed the trusts if you are planning to re-create them. The following tasks for removing a manually created trust are described in this objective: Validating and removing trusts Modifying Name Suffix Routing Settings

Validating and removing trusts


After a trust has been established, you may need to verify that it is working as designed, or that communications over the trust are working, by using Active Directory tools to validate the trust's connectivity. It may also be necessary to remove an existing, manually created trust when connectivity between two domains is no longer necessary. Task requirements

You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to create a realm trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). To complete this task, perform the following procedures: Validate a trust Remove a manually created trust

Validate a trust
You can validate all trusts that are made between domains, but you cannot validate realm trusts. You can validate a trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to create a realm trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To validate a trust
Using the Windows interface Using the command line

Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that contains the trust that you want

to validate, and then click Properties. 3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the trust to be validated, and then click Properties. 4. Click Validate. 5. Do one of the following, and then click OK: Click No, do not validate the incoming trust.

If you click this option, it is recommended that you repeat this procedure for the reciprocal domain. Click Yes, validate the incoming trust.

If you click this option, you must type a user account and password with administrative credentials for the reciprocal domain.

Using the command line 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: netdom trust TrustingDomainName /d:TrustedDomainName /verify

Term TrustingDomainName

Definition Specifies the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the trusting domain in the trust that is being created. Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created.

TrustedDomainName

Remove a manually created trust


It is possible to remove manually created shortcut trusts, external trusts, realm trusts, or forest trusts. It is not possible to remove default, two-way, transitive trusts between domains in a forest. It is particularly important to verify that you successfully remove trusts if you are planning to re-create them. You can remove a manually created trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about the Netdom command-line tool, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To remove a manually created trust


Using the Windows interface Using a command prompt

Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that contains the trust that you want to remove, and then click Properties. 3. Click the Trusts tab. 4. In either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the trust to be removed, and then click Remove.

5. Do one of the following, and then click OK: Click No, remove the trust from the local domain only.

If you click this option, it is recommended that you repeat this procedure for the reciprocal domain. Click Yes, remove the trust from both the local domain and the other domain. If you click this option, you must type a user account and password with administrative credentials for the reciprocal domain.

Using the command line 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: netdom trust TrustingDomainName /d:TrustedDomainName /remove/UserD:User /PasswordD:*

Term TrustingDomainName

Definition Specifies the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the trusting domain in the trust that is being created. Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created.

TrustedDomainName

Note If you are using Netdom to remove a realm trust, you must add the /force option to the end of the command (after /remove) to remove the trust successfully.

Modifying Name Suffix Routing Settings


Name suffix routing is a mechanism that is used to manage how authentication requests are routed across Windows Server 2003 forests that are joined by forest trusts. To simplify the administration of authentication requests, when a forest trust is created, all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or Domain Name System (DNS) forest or domain tree name that is not subordinate to any other name suffix. For example, the DNS forest name fabrikam.com is a unique name suffix within the fabrikam.com forest. For more information about name suffix routing, see Routing name suffixes across forests on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=35414). Note You cannot enable a name suffix that is in conflict. If the conflict is with a local UPN name suffix, you must remove the local UPN name suffix before you can enable the routing name. If the conflict is with a name that is claimed by another trust partner, you must disable the name in the other trust before it can be enabled for this trust. Task requirements You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to create a realm trust, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). To complete this task, perform any of the following procedures: Modify the routing status of a name suffix Enable or disable an existing name suffix for routing Exclude name suffixes from routing to local forests

Modify the routing status of a name suffix


You can change the routing status (enabled or disabled) of a name suffix by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to modify name suffix routing settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To modify the routing status of a name suffix


Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the domain that you want to administer, and then click Properties. 3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts)or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties. 4. On the Name Suffix Routing tab, under Name suffixes in the x.x forest, click the suffix for which you want to modify routing status, and then click Edit. 5. In Existing name suffixes in x.x, click the suffix that you want to modify, and then click Enable or Disable.

See Also

Enable or disable an existing name suffix for routing


You can use this procedure to prevent authentication requests for specific name suffixes from being routed to a forest, or you can use this procedure to allow authentication requests for specific name suffixes to be routed to a forest. You can enable or disable an existing name suffix for routing by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to modify name suffix routing settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Note When you disable a name suffix, all children of that Domain Name System (DNS) name will also be disabled. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To enable or disable an existing name suffix for routing


Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to administer, and then click Properties. 3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties. 4. Click the Name Suffix Routing tab, and then, under Name suffixes in the x.x forest, do one of the following:

To enable a name suffix, click the suffix that you want to enable, and then click Enable. If the Enable button is unavailable, the name suffix is already enabled. To disable a name suffix, click the suffix that you want to disable, and then click Disable. If the Disable button is unavailable, the name suffix is already disabled.

See Also

Exclude name suffixes from routing to local forests


You can exclude existing name suffixes from routing to local forests by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to modify name suffix routing settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Note When you exclude a name suffix, all children of that Domain Name System (DNS) name will also be excluded. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To exclude name suffixes from routing to local forests


Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to administer, and then click Properties.

3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties. 4. On the Name Suffix Routing tab, under Name suffixes in the x.x forest, click the unique name suffix to exclude from routing, and then click Edit. 5. In Name suffixes to exclude from routing to x.x, click Add, type a DNS name suffix that is subordinate to the unique name suffix, and then click OK.

See Also

Securing Domain and Forest Trusts


When you create a new trust in an existing Active Directory forest, all communications over that trust are tightly secured. However, when you create a trust between your domain and another domain outside your forest, there are certain security issues involved. For example, you might need to configure security identifier (SID) filtering to deny one domain the right to provide credentials for another domain. You can enable or disable SID filtering for external trusts or forest trusts. The following tasks for securing domain and forest trusts are described in this objective: Configuring SID Filtering Settings Configuring Selective Authentication Settings

For more information about how the security settings for domain and forest trusts work, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413).

Configuring SID Filtering Settings


Security principals in Active Directory have an attribute called SIDHistory to which domain administrators can add users old security identifiers (SIDs). This is useful during Active Directory migrations because administrators do not need to modify access control lists (ACLs) on large numbers of resources and users can use their old SIDs to access resources. However, under some circumstances it is possible for domain administrators to use the SIDHistory attribute to associate SIDs with new user accounts, granting themselves unauthorized rights. To help prevent this type of attack, Windows Server 2003

automatically enables SID filtering on all external trusts and forest trusts that are created by a Windows Server 2003 domain controller. External trusts that are created using domain controllers running Windows 2000 Server with Service Pack 3 (SP3) or earlier must be manually configured to enable SID filtering. Note You cannot turn off the default behavior in Windows Server 2003 that enables SID filtering for newly created external and forest trusts. External trusts that are created from domain controllers running Windows 2000 Server with SP3 or earlier do not enforce SID filtering by default. You can use SID filtering to filter out migrated SIDs that are stored in SIDHistory from specific domains. For example, where an external trust relationship exists so that the Noam domain (running Windows 2000 Server domain controllers) trusts the Acquired domain (also running Windows 2000 Server domain controllers), an administrator of the Noam domain can manually 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 that are stored in SIDHistory) to be discarded. Note Do not apply SID filtering to domains within a forest, because doing so removes SIDs that are required for Active Directory replication, and it causes authentication to fail for users from domains that are trusted transitively through the isolated domain. To further secure your forest, consider enabling SID filtering on all existing external trusts that are created by domain controllers running Windows 2000 Server SP3 or earlier. You can do this by using Netdom.exe to enable SID filtering on existing external trusts or by recreating these external trusts from a domain controller running Windows Server 2003 or Windows 2000 Server with Service Pack 4 (SP4) or later. For more information about how to enable SID filtering on trusts that are created by Windows 2000 Server domain controllers, see the Windows 2000 Active Directory Operations Guide the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=18545). For more information about how SID filtering works, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413). Task requirements You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to configure SID filtering settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). To complete this task, perform the following procedures: Disable SID filtering Reapply SID filtering

Disable SID filtering


Although it is not recommended, you can disable security identifier (SID) filtering for an external trust or forest trust by using the Netdom.exe tool. You should consider disabling SID filtering only in the following situations: You have an equally high level of confidence in the administrators who have physical access to domain controllers in the trusted domain and the administrators with such access in the trusting domain. You have a strict requirement to assign universal groups to resources in the trusting domain, even when those groups were not created in the trusted domain. Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant those users access to resources in the trusting domain based on the SIDHistory attribute. For more information about how SID filtering works, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413). You can disable SID filtering by using the Netdom command-line tool. For more information about the Netdom command-line tool, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To disable SID filtering 1. To disable SID filtering for the trusting domain, open a Command Prompt.

2. Type the following command, and then press ENTER: Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd Value TrustingDomainName Description The Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the trusting domain in the trust that is being created. The DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created. The user account name with the appropriate administrator credentials to modify the trust. The password of the user account in domainadministratorAcct.

TrustedDomainName

domainadministratorAcct

domainadminpwd

Note You can enable or disable SID filtering only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filtering in the trusted domain by using the domain administrators credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the command-line syntax.

Reapply SID filtering


You can reapply security identifier (SID) filtering to an external or forest trust that has had SID filtering disabled. By default, Windows Server 2003 automatically enables SID filtering on all external trusts and forest trusts that are created by a Windows Server 2003 domain controller. For more information about how SID filtering works, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413).

You can reapply SID filtering by using the Netdom command-line tool. For more information about the Netdom command-line tool, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To reapply SID filtering 1. To reapply SID filtering for the trusting domain, open a Command Prompt. 2. Type the following syntax, and then press ENTER: Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:Yes /usero:domainadministratorAcct /passwordo:domainadminpwd

Term TrustingDomainName

Definition The Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the trusting domain in the trust that is being created. The DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created. The user account name with the appropriate administrator credentials to modify the trust. The password of the user account in domainadministratorAcct.

TrustedDomainName

domainadministratorAcct

domainadminpwd

Configuring Selective Authentication Settings


Trusts that are created between Windows Server 2003 forests can use legacy authentication settings (settings that were used in Windows 2000 Server) or selective authentication. Selective authentication is a security setting that can be enabled on external trusts and forest trusts between Windows Server 2003 forests. Selective authentication provides Active Directory administrators who manage a trusting forest more control over which groups of users in a trusted forest can access shared resources in the trusting forest. Because creating an external trust or forest trust provides a pathway for all authentication requests between the forests, this increased control is especially important when administrators need to grant access to shared resources in their organizations forest to a limited set of users in another organizations forest. For more information about how selective authentication settings work, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413). Task requirements You can use either of the following tools to perform the procedures for this task: Active Directory Domains and Trusts Netdom.exe

For more information about how to use the Netdom command-line tool to configure selective authentication settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). To complete this task, perform the following procedures: Enable selective authentication over an external trust Enable selective authentication over a forest trust Enable domain-wide authentication over an external trust Enable forest-wide authentication over a forest trust

Grant the Allowed to Authenticate permission on computers in the trusting domain or forest

Enable selective authentication over an external trust


Selective authentication over an external trust restricts access to only those users in a trusted domain who have been explicitly given authentication permissions to computer objects (resource computers) that reside in the trusting domain. To explicitly give authentication permissions to computer objects in the trusting domain to certain users, administrators must grant those users the Allowed to Authenticate permission in Active Directory. For more information, see Grant the Allowed to Authenticate permission on computers in the trusting domain or forest. For more information about how selective authentication works, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=35413). You can enable selective authentication over an external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to configure selective authentication settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To enable selective authentication over an external trust


Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to administer, and then click Properties. 3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the external trust that you want to administer, and then click Properties. 4. On the Authentication tab, click Selective authentication, and then click

OK. Note Only the authentication settings for the outgoing trust are displayed when you click Properties and then click the Authentication tab in Active Directory Domains and Trusts. To view the correct authentication settings for the incoming side of a twoway, external trust, connect to a domain controller in the trusted domain, and then use Active Directory Domains and Trusts to view the authentication settings for the outgoing side of the same trust.

Enable selective authentication over a forest trust


Selective authentication over a forest trust restricts access to only those users in a trusted forest who have been explicitly given authentication permissions to computer objects (resource computers) that reside in the trusting forest. To explicitly give authentication permissions to computer objects in the trusting forest to certain users, Administrators must grant those users the Allowed to Authenticate permission in Active Directory. For more information, see Grant the Allowed to Authenticate permission on computers in the trusting domain or forest. For more information about how selective authentication works, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413). You can enable selective authentication over a forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to configure selective authentication settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory.

To enable selective authentication over a forest trust


Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node for the forest root domain, and then click Properties. 3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties. 4. On the Authentication tab, click Selective authentication, and then click OK. Note Only the authentication settings for the outgoing trust are displayed when you click Properties and then click the Authentication tab in Active Directory Domains and Trusts. To view the correct authentication settings for the incoming side of a twoway, forest trust, connect to a domain controller in the forest root domain of the trusted forest, and then use Active Directory Domains and Trusts to view the authentication settings for the outgoing side of the same trust.

See Also

Enable domain-wide authentication over an external trust


The domain-wide authentication setting permits unrestricted access by any users in the trusted domain to all available shared resources in the trusting domain. This is the default authentication setting for external trusts, and it is representative of the way authentications were routed without restriction over Windows 2000 Server trusts. For more information about the domain-wide authentication setting, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413).

You can enable domain-wide authentication over an external trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to configure selective authentication settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To enable domain-wide authentication over an external trust


Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain that you want to administer, and then click Properties. 3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the external trust that you want to administer, and then click Properties. 4. On the Authentication tab, click Domain-wide authentication, and then click OK. Note Only the authentication settings for the outgoing trust are displayed when you click Properties and then click the Authentication tab in Active Directory Domains and Trusts. To view the correct authentication settings for the incoming side of a twoway, external trust, connect to a domain controller in the trusted domain, and then use Active Directory Domains and Trusts to view the authentication settings for the outgoing side of the same trust.

Enable forest-wide authentication over a forest trust


The forest-wide authentication setting permits unrestricted access by any users in the trusted forest to all available shared resources in any of the domains in the trusting forest. This is the default authentication setting for forest trusts, and it is representative of the way authentications were routed without restriction over Windows 2000 Server trusts. For more information about the forest-wide authentication setting, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413). You can enable forest-wide authentication over a forest trust by using the New Trust Wizard in Active Directory Domains and Trusts or by using the Netdom command-line tool. For more information about how to use the Netdom command-line tool to configure selective authentication settings, see "Netdom.exe: Windows Domain Manager" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41700). Administrative credentials To complete this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To enable forest-wide authentication over a forest trust


Using the Windows interface 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the forest root domain, and then click Properties. 3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties. 4. On the Authentication tab, click Forest-wide authentication, and then click OK.

Note Only the authentication settings for the outgoing trust are displayed when you click Properties and then click the Authentication tab in Active Directory Domains and Trusts. To view the correct authentication settings for the incoming side of a twoway, forest trust, connect to a domain controller in the trusted domain (the forest root domain in the other forest), and then use Active Directory Domains and Trusts to view the authentication settings for the outgoing side of the same trust.

Grant the Allowed to Authenticate permission on computers in the trusting domain or forest
For users in a trusted Windows Server 2003 domain or forest to be able to access resources in a trusting Windows Server 2003 domain or forest, where the trust authentication setting has been set to selective authentication, each user must be explicitly granted the Allowed to Authenticate permission on the security descriptor of the computer objects (resource computers) that reside in the trusting domain or forest. For more information about how the Allowed to Authenticate permission works, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413). Note The Allowed to Authenticate permission can be set on computer objects that represent member servers running Windows NT Server 4.0, Windows 2000 Server, and Windows Server 2003. Note By default, only members of the Account Operators, Administrators, Domain Admins, Enterprise Admins, and SYSTEM security groups that are located in the trusting domain can modify the Allowed to Authenticate permission. To enable access to resources over an external trust or forest trust that is set to selective authentication, complete the following procedure by using Active Directory Users and Computers from the trusting domain. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory.

To grant the Allowed to Authenticate permission on computers in the trusting domain or forest
Using the Windows interface 1. Open Active Directory Users and Computers. 2. In the console tree, click the Computers container or the container where your computer objects reside. 3. Right-click the computer object that you want users in the trusted domain or forest to access, and then click Properties. 4. On the Security tab, do one of the following: In Group or user names, click the user names or group names for which you want to grant access to this computer, select the Allow check box next to the Allowed to Authenticate permission, and then click OK. Click Add. In Enter the object names to select, type the name of the user object or group object for which you want to grant access to this resource computer, and then click OK. Select the Allow check box next to the Allowed to Authenticate permission, and then click OK.

Appendix: New Trust Wizard Pages


Understanding how user input is handled during the trust creation process will help you provide information when it is most necessary and help you better prepare for your specific procedure. This section explains the two most complex pages in the New Trust Wizard: Direction of Trust Sides of Trust

Direction of Trust
The Direction of Trust page in the New Trust Wizard is configured by an administrator in one domain to determine whether authentication requests should be routed from this

domain to a specified domain, from the specified domain to this domain, or freely between both domains. The following options are available on the Direction of Trust page: Two-way: A two-way trust allows authentication requests that are sent by users in either domain or forest to be routed successfully to resources in either of the two domains or forests. One-way: incoming: A one-way, incoming trust allows authentication requests that are sent by users in your domain or forest (the domain or forest where you started the New Trust Wizard) to be routed successfully to resources in the other domain or forest. One-way: outgoing: A one-way, outgoing trust allows authentication requests that are sent by users in the other domain (the domain or forest that you are indicating in the New Trust Wizard as the specified domain or forest) to be routed successfully to resources in your domain or forest. These options are explained in the following sections.

Wizard Option: Two-way


Use this option when you want to share resources equally between two domains or forests for all of the users that reside in both domains or forests. A two-way trust allows authentication requests that are sent by users in a trusted domain or forest to be routed successfully to the trusting domain or forest. Note Traditionally, documentation about domain and forest trusts have used the terms trusting and trusted to help administrators pinpoint the direction of the trust. Although this terminology is still used today to define and conceptualize how trusts work, it varies from the terminology that is used in the New Trust Wizard to help administrators determine the direction of trust.

Wizard Option: One-way: incoming


Use this option when you want to allow authentication requests to be routed from your domain or forest (referred to as this domain or this forest in the wizard) to resources residing in a second domain or forest (referred to as specified domain or specified forest in the wizard). One-way in One-way: incoming means that this selection will create a one-way trust that can route authentications to resources in only one direction, while user access to those resources flows in the other direction. Incoming in One-way: incoming refers to the direction of the trust itself, not the direction in which authentication requests will flow. In other words, as shown in the following illustration, a "one-way incoming trust"

means that your domain or forest will be the domain or forest that receives access to the resources in the other domain.

Wizard Option: One-way: outgoing


Use this option when you want to allow authentication requests to be routed to your domain or forest (referred to as this domain or this forest in the wizard) from users residing in a second domain or forest (referred to as specified domain or specified forest in the wizard). One-way in One-way: outgoing means that this selection will create a one-way trust that can route authentications to resources in only one direction, while user access to those resources flows in the other direction. Outgoing in One-way: outgoing refers to the direction of the trust itself, not the direction in which authentication requests will flow. In other words, as shown in the following illustration, a "one-way, outgoing trust" means that

your domain or forest will provide access to resources that are located in your domain to users who are located in the other domain or forest.

Sides of Trust
In Windows NT 4.0 and Windows 2000, the only way to create trusts using the graphical user interface (GUI) was incrementally one side of the trust at a time. When you create external trusts, shortcut trusts, realm trusts, or forest trusts in Windows Server 2003, you now have the option to create each side of the trust separately or both sides of the trust simultaneously.

Wizard Option: This domain only


Use this option when you want to create each side of the trust separately, which means that you must run the New Trust Wizard twice once for each domain in the trust. Although the New Trust Wizard presents a different experience than previous version of Windows Server operating systems, this option provides behavior that is similar to the way that trusts were created in Windows NT 4.0 and Windows 2000. When you create trusts using this method, you must supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords.

Wizard Option: Both this domain and the specified domain


This option provides administrators who possess the appropriate domain credentials for both domains in the trust relationship with the option to quickly create both sides of a trust by completing a single instance of the New Trust Wizard. When you select this option, a strong trust password is automatically generated for you. For this selection to be successful, the administrator running the wizard must acquire the appropriate administrative credentials for each domain in the trust relationship

Administering the Windows Time Service


Time synchronization is critical for the proper operation of many Windows services and line-of-business applications. The Windows Time service uses the Network Time Protocol (NTP) to synchronize computer clocks on the network so that an accurate clock value, or time stamp, can be assigned to network validation and resource access requests. This guide provides information for administering the Windows Time service in the Microsoft Windows Server 2003 operating system. In this guide Introduction to Administering the Windows Time Service Managing the Windows Time Service

Acknowledgements Published: March 2005 Applies to: Windows Server 2003 Produced by: Microsoft Windows Server User Assistance team

Writer: Shala Brandolini Editor: Justin Hall

Introduction to Administering the Windows Time Service


The Microsoft Windows Server 2003 Windows Time service, also known as W32Time, synchronizes the date and time for all computers running on a Windows Server 2003 network. The service integrates NTP and time providers, making it a reliable and scalable time service for enterprise administrators. The purpose of the Windows Time service is to make sure that all computers that are running Windows 2000 or later versions in an organization use a common time. To guarantee appropriate common time usage, the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops. By default, Windows-based computers use the following hierarchy: All client desktop computers nominate the authenticating domain controller as their in-bound time partner. All member servers follow the same process as client desktop computers.

Domain controllers may nominate the primary domain controller (PDC) operations master as their in-bound time partner but may use a parent domain controller based on stratum numbering. All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner. Following this hierarchy, the PDC operations master at the root of the forest becomes authoritative for the organization. The authoritative time source at the root of the forest can acquire its time by connecting to an external NTP server, which is connected to a hardware device by means of a telephone or the Internet. Organizations such as the United States Naval Observatory provide NTP servers that are connected to extremely reliable reference clocks. If you need highly accurate time synchronization, but cannot connect to an external time source on the Internet we recommend that you configure a hardware clock, such as a radio or GPS device, as the time source for the PDC. There are many consumer and enterprise devices that use the Network Time Protocol (NTP), allowing you to install the device on an internal network for usage with the PDC.

For a detailed technical reference of the Windows Time service, including complete documentation of the w32tm tool and the time service registry settings, see the Windows Time Service Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=40648).

Managing the Windows Time Service


You initially configure the Windows 2003 Time service (W32Time) when you deploy your Active Directory forest root domain. Thereafter, it requires little day-to-day management. After you make changes on your network however, including when you add certain client computers, move the PDC emulator operations master role, or simply change the time source for you network, you might need to perform some of the following tasks: Configuring a time source for the forest Configuring Windows-based clients to synchronize time Restoring Windows Time service to default settings

Configuring a time source for the forest


After initial deployment of your network, you typically reconfigure the time service on the PDC emulator only in two situations: If you move the PDC emulator role to a different computer. In this case, you must configure the time service for the new PDC emulator role holder. If you change the time source for the PDC emulator. For example, if you change from synchronizing with an external source to a hardware device. Follow these best practices for configuring the time source on the forest-root PDC emulator, in this order of preference: Install a hardware clock, such as a radio or GPS device, as the source for the PDC. There are many consumer and enterprise devices that use the Network Time Protocol (NTP), allowing you to install the device on an internal network for usage with the PDC. Configure the Windows Time service to synchronize with an external time server. External time servers allow users to synchronize computer clocks by means of dial-up, network, and radio links.

The Microsoft time server (time.windows.com) uses NIST, the National Institute of Standards and Technology, located in Boulder, Colorado, as its external time provider. NIST provides the Automated Computer Time Service (ACTS), which can set a computer clock with an uncertainty of less than 10 milliseconds. The U.S. Naval Observatory (USNO) Time Service Department in Washington D.C. is another source for accurate time synchronization in the United States. Many other sites exist throughout the world that can be used for time synchronization. To find them, search for "time synchronization" on the Internet. Note Because synchronization with an external time source is not authenticated, it is less secure. The PDC emulator of the forest root domain is customarily the authoritative time source for the forest and the computer that is usually configured to retrieve time from an external source. However, if the PDC emulator is not configured to retrieve time from another time source but is the reliable time source for the domain, configure it to synchronize from its own internal hardware clock. The role of PDC emulator can move between computers, meaning that every time the role of PDC emulator moves, the time service must be reconfigured on the new PDC emulator, and the manual configuration must be removed from the original PDC emulator. To avoid this process, configure one domain controller in the forest root domain that is not the PDC emulator, as the reliable time source and manually configure it to point to an external time source. Then, no matter which computer is the PDC emulator, the root of the time service stays the same and thus remains properly configured. If you choose to implement another time synchronization product that uses the NTP protocol on your network, you must disable the Windows Time service. All NTP servers need access to UDP port 123. If W32Time is running on a Windows 2003based computer, port 123 will remain occupied. Task requirements The following tools are required to perform the procedures for this task: W32tm.exe Services snap-in if you need to disable the Windows Time service

Perform the following procedures as needed to configure a time source for your forest: 1. Configure the Windows Time service on the PDC emulator 2. If you move the role of the PDC emulator to a new domain controller, Change the Windows Time service configuration on the previous PDC emulator.

3. If you anticipate moving the PDC emulator role and do not want to reconfigure the Windows Time service afterwards, Configure a domain controller in the parent domain as a reliable time source. 4. If your PDC emulator is not configured to retrieve time from another time source but is the reliable time source for the domain, Configure the PDC emulator to synchronize from its internal hardware clock. 5. If you are implementing a time synchronization product other than the Windows Time service in your environment that uses the NTP protocol, Disable the Windows Time service to free UDP port 123 on the network.

Configure the Windows Time service on the PDC emulator


Configure the Windows Time service on the PDC emulator when you deploy a new forest root domain or when you move the role of the PDC emulator in the forest root domain to a new domain controller. If you move the role of the PDC emulator to a new domain controller you must also Change the Windows Time service configuration on the previous PDC emulator. Before you configure the time service on the PDC emulator, you can determine the time difference between it and the source as a means to test basic NTP communication. After completing the configuration on the PDC emulator be sure to monitor the System log in Event Viewer for W32Time errors. Note For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42984). Administrative Credentials To perform this procedure locally on the PDC emulator, you must be a member of the Administrators group. To perform this procedure from a remote computer, you must be a member of the Domain Admins group. To configure the Windows Time service on the PDC emulator 1. Open a Command Prompt. 2. Type the following command to display the time difference between the local

computer and a target computer, and then press ENTER: w32tm /stripchart /computer:target /samples:n/dataonly Value target Definition Specifies the DNS name or IP address of the NTP server that you are comparing the local computer's time against, such as time.windows.com. Specifies the number of time samples that will be returned from the target computer to test basic NTP communication.

3. Open UDP port 123 for outgoing traffic if needed. 4. Open UDP port 123 (or a different port you have selected) for incoming NTP traffic. 5. Type the following command to configure the PDC emulator and then press ENTER: w32tm /config /manualpeerlist:peers /syncfromflags:manual /reliable:yes /update where peers specifies the list of DNS names and/or IP addresses of the NTP time source that the PDC emulator synchronizes from. For example, you can specify time.windows.com. When specifying multiple peers, use a space as the delimiter and enclose them in quotation marks.

Change the Windows Time service configuration on the previous PDC emulator
Use the following procedure to change the Windows Time service configuration on the previous PDC emulator after you transfer the role to a new domain controller. The previous

PDC emulator will now automatically synchronize time with the domain hierarchy, getting it's time from the new reliable time source. Note For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42984). Administrative Credentials To perform this procedure locally on the PDC emulator, you must be a member of the Administrators group. To perform this procedure from a remote computer, you must be a member of the Domain Admins group. To change the Windows Time service configuration on the previous PDC emulator 1. Open a Command Prompt. 2. Type the following command and then press ENTER: w32tm /config /syncfromflags:domhier /reliable:no /update 3. Type the following command and then press ENTER: net stop w32time 4. Type the following command and then press ENTER: net start w32time

Configure a domain controller in the parent domain as a reliable time source


Use this procedure to configure a domain controller as a reliable time source if you anticipate moving the PDC emulator role and do not want to reconfigure the Windows Time service afterward. If you are configuring a domain controller as a reliable time source for the forest root domain, perform the procedure Change the Windows Time service configuration on the previous PDC emulator in addition to this procedure. Although you

have not moved the PDC emulator role, you must still configure the existing PDC emulator to no longer be the reliable time source for the domain. Note For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42984). Administrative Credentials To perform this procedure locally on the domain controller, you must be a member of the Administrators group. To perform this procedure from a remote computer, you must be a member of the Domain Admins group. To configure a domain controller in the parent domain as a reliable time source 1. Open a Command Prompt. 2. Type the following command and press ENTER: W32tm /config /reliable:yes /update

Configure the PDC emulator to synchronize from its internal hardware clock
Use the following procedure to configure the PDC emulator in the forest root domain to synchronize from its internal hardware clock and remain the reliable time source in the forest root domain. Note For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42984). Administrative Credentials To perform this procedure locally on the PDC emulator, you must be a member of the Administrators group. To perform this procedure from a remote computer, you must be a member of the Domain Admins group.

To configure the PDC emulator to synchronize from its internal hardware clock 1. Open a Command Prompt. 2. Type the following command and then press ENTER: w32tm /config /syncfromflags:domhier /reliable:yes /update 3. Type the following command and then press ENTER: net stop w32time 4. Type the following command and then press ENTER: net start w32time

Disable the Windows Time service


Use this procedure to disable the Windows Time service if you choose to implement another time synchronization product that uses the NTP protocol. Administrative Credentials To perform this procedure on the local computer, you must be a local Administrator on the PDC emulator. To perform this procedure on a remote computer, you must be a member of the Domain Admins group. To disable the Windows Time service 1. Open the Services snap-in. 2. Right-click Windows Time, and select Properties. The Windows Time Properties dialog box appears. 3. In the Startup type box, select Disabled from the drop-down menu. 4. Click OK. Verify that the Startup Type for the time service appears as Disabled.

Configuring Windows-based clients to synchronize time


Certain Windows-based client computers do not automatically synchronize their time with the Active Directory domain. The following client computers do not automatically synchronize to the domain time by using the Windows Time service: Client computers that run in a pre-Windows 2000 domain environment. Client computers that run in a UNIX environment. Computers that are not joined to a domain.

Configure these computers to request time from a particular source, such as a domain controller in the domain. If you do not specify a source that is synchronized with the domain, each computers internal hardware clock governs its time. Task requirements The following tool is required to perform the procedures for this task: W32tm

Use either of the following procedures to configure your Windows-based clients to synchronize time: -or Configure a client computer for automatic domain time synchronization Configure a manual time source for a selected client computer

Configure a manual time source for a selected client computer


Before you configure a manual time source for a client computer, you can determine the time difference between it and the source as a means to test basic NTP communication. After completing the configuration on the selected client computer, be sure to monitor the System log in Event Viewer for W32Time errors.

Note For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42984). Administrative Credentials To perform this procedure, you must be a member of the Administrators group on the local computer. To perform this procedure from a remote computer, you must be a member of the Domain Admins group. To configure a manual time source for a selected client computer 1. Open a Command Prompt. 2. Type the following command to display the time difference between the local computer and a target computer, and then press ENTER: w32tm /stripchart /computer:target /samples:n/dataonly Value target Definition Specifies the DNS name or IP address of the NTP server that you comparing the local computer's time against. Specifies the number of time samples that will be returned from the target computer to test basic NTP communication.

3. Open UDP port 123 for outgoing traffic on firewall if needed. 4. Open UDP port 123 (or a different port you have selected) for incoming NTP traffic. 5. Type the following command to configure a manual time source for the selected computer and then press ENTER: w32tm /config /manualpeerlist:peers /syncfromflags:manual /update where peers specifies the list of DNS names or IP addresses of the NTP time source(s) that the selected computer will synchronize from. When specifying multiple peers, use a space as the delimiter and enclose them in quotation marks.

Configure a client computer for automatic domain time synchronization


Some computers that are joined to a domain are configured to synchronize from a manual time source. Use the following procedure to configure a client computer that is currently synchronizing with a manually specified computer, to automatically synchronize time with the domain hierarchy. Note For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42984). Administrative Credentials To perform this procedure, you must be a member of the Administrators group on the local computer. To perform this procedure from a remote computer, you must be a member of the Domain Admins group. To configure a client computer for automatic domain time synchronization 1. Open a Command Prompt. 2. Type the following command and then press ENTER: w32tm /config /syncfromflags:domhier /update 3. Type the following command and then press ENTER: net stop w32time 4. Type the following command and then press ENTER: net start w32time

Restoring Windows Time service to default settings


If the local Windows Time service settings are incorrectly configured, restoring the Windows Time service to its default settings might be more efficient than troubleshooting the problem. Task requirements The following tools are required to perform the procedures for this task: W32tm.exe

Perform the following procedure to restore local Windows Time service to the default settings: Restore Windows Time service on local computer to default settings

Restore Windows Time service on local computer to default settings


Use this procedure to restore the Windows Time service on the local computer to the default settings. Note For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42984). Administrative Credentials To perform this procedure on the local computer, you must be a member of the Administrators group. To perform this procedure on a remote computer, you must be a member of the Domain Admins group. To restore Windows Time service on local computer to default settings 1. Open a Command Prompt. 2. Type the following command and then press ENTER: net stop w32time

3. Type the following command and then press ENTER: w32tm /unregister 4. Type the following command and then press ENTER: w32tm /register 5. Type the following command and then press ENTER: net start w32time

Administering SYSVOL
This SYSVOL Administering guide provides administering information for the Active Directory SYSVOL shared folder in the Microsoft Windows Server 2003 operating system. In this guide Introduction to Administering SYSVOL Managing SYSVOL

Acknowledgements Published: March 2005 Updated: Applies to: Windows Server 2003 Produced by: Microsoft Windows Server User Assistance team Writer: Mary Hillman Editor: Jim Becker

Introduction to Administering SYSVOL


The Windows Server 2003 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 important elements of Group Policy objects (GPOs) and scripts so that the File Replication service (FRS) can distribute them to other domain controllers within that domain.

Note Only the Group Policy template (GPT) is replicated by SYSVOL. The Group Policy container (GPC) is replicated through Active Directory replication. To be effective, both parts must be available on a domain controller. 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. 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. This objective describes the basic tasks required for managing SYSVOL in order to maintain capacity and performance of SYSVOL, for hardware maintenance, or for data organization. Key considerations for administering SYSVOL To manage SYSVOL, ensure that FRS properly replicates the SYSVOL data and that enough space is provided to store SYSVOL. Implement a monitoring system to detect low disk space and potential FRS disruptions so that you can address those issues before the system stops replicating. A useful tool for this is the Ultrasound utility, which can be downloaded from www.microsoft.com, by searching for Ultrasound. Other key considerations for managing SYSVOL are: Capacity.

Depending upon the configuration of your domain, SYSVOL can require a significant amount of disk space to function properly. During the initial deployment, SYSVOL might be allocated adequate disk space to function. However, as your Active Directory grows in size and complexity, the required capacity can exceed the available disk space. If you receive indications that disk space is low, determine if the cause is due to inadequate physical space on the disk or a registry setting that limits the size of the staging area. By modifying a setting in the registry, you can allocate more staging area space, rather than relocating SYSVOL or the staging area. Increasing the space allocation in the registry is much faster and easier than relocation 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. For example, editing a GPO can potentially force a GPO-level replication. 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 could 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. Backing up Group Policy objects (GPOs).

The successful operation of Group Policy is heavily dependant on the reliable operation of SYSVOL. Key components of the GPO exist in the SYSVOL (in the policies subdirectory) and it is essential that these remain in sync with related components in Active Directory. Therefore, backing up only the SYSVOL component does not represent a full and complete backup of your GPOs. The Group Policy Management Console (GPMC) provides both UIbased and scriptable methods for backing up GPOs. It is important that you back up GPOs as part of your regular backup/disaster recovery processes. Soon after installation of a new domain, the default domain and default domain controllers' GPOs should be backed up. They should also be backed up after any subsequent changes are made. Understanding the SYSVOL folder structure 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. 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 contents 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: %systemroot%\SYSVOL %systemroot%\SYSVOL\Domain

%systemroot%\SYSVOL\Domain\DO_NOT_REMOVE_Ntfrs_ Preinstalled_Directory %systemroot%\SYSVOL\Domain\Policies %systemroot%\SYSVOL\Domain\Scripts %systemroot%\SYSVOL\Staging %systemroot%\SYSVOL\Staging\Domain %systemroot%\SYSVOL\Staging Areas %systemroot%\SYSVOL\Staging Areas FQDN

%systemroot%\SYSVOL\Sysvol %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 Show hidden files and folders. 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.

Managing SYSVOL
The following tasks for managing SYSVOL are described in this objective:

Changing the Space Allocated to the Staging Area Relocating the Staging Area Relocating SYSVOL Manually Updating the System Volume Path Restoring and Rebuilding SYSVOL

Changing the Space Allocated to the Staging Area


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. The default size of the staging area is 660 megabytes (MB). The minimum size is 10 MB and the maximum size is 2 terabytes. You can adjust the size limit of the Staging 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 329491 in the Microsoft Knowledge Base. Task requirements The following tools are required to perform the procedures for this task: Net.exe Regedit.exe Event Viewer

To complete this task, perform the following procedures in order: 1. Stop the File Replication service 2. Change the space allocated to the Staging Area folder 3. Start the File Replication service

Stop the File Replication service


Use this procedure to stop the File Replication service. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To stop the File Replication service 1. Open a Command Prompt. 2. Type the following command and then press Enter: net stop ntfrs

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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To change the space allocated to the Staging Area folder 1. Click Start, and then click Run. 2. In the Run dialog box, type regedit and then press Enter. 3. In the Registry Editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Paramete

rs. 4. Double-click Staging Space Limit in KB to open the Edit DWord Value dialog box. 5. In the Base frame, select Decimal. 6. For Value Data enter a value from 10000 through 2000000000. Do not use commas. Click OK. 7. Close the Registry Editor.

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. Administrative Credentials To perform this procedure you must be a member of the Domain Admins group in Active Directory. To start the File Replication service 1. Open a Command Prompt. 2. Type the following command, and then press Enter: net start ntfrs 3. 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.

Relocating the Staging Area


By default, the Active Directory Installation Wizard installs the Staging Area folder within the SYSVOL. The Active Directory Installation Wizard creates two foldersStaging and

Staging Areawhich FRS uses for the staging process. When you relocate the staging area, you can change the name. Ensure that you identify the proper area in case it 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 Area 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. Except where noted, perform these procedures on the domain controller that contains the Staging Area folder that you want to relocate. Task requirements To perform this task it is necessary that you understand the folder structure used by the system volume. For more information, see Introduction to Administering SYSVOL. The following tools are required to perform the procedures for this task: Active Directory Sites and Services (Administrative Tool) Event Viewer Net.exe Dcdiag.exe (Windows Support Tools) Regedit.exe ADSI Edit.msc (Windows Support Tools) Linkd.exe (Windows Server 2003 Resource Kit Tools)

Note To create or update junctions, you need the Linkd.exe tool supplied with Windows Server 2003 Resource Kit Tools on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=16544. Linkd allows you to create, delete, update, and view the links that are stored in junction points. To complete this task, perform the following procedures in order: 1. Identify replication partners 2. Check the status of the shared SYSVOL 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 replication with other domain controllers 4. Gather the SYSVOL path information 5. Reset the File Replication service staging folder to a different logical drive

Identify replication partners


Use this procedure to examine the Connection objects for a domain controller and determine its replication partners. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To identify replication partners 1. Open Active Directory Sites and Services. 2. In the console tree, expand the Sites container to display the list of sites. 3. Double-click the site that contains the domain controller for which you want to determine Connection objects. Note If you do not know the site in which the domain controller is located, 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. 4. Expand the Servers folder to display the list of servers in that site. 5. Expand the name of your domain controller to display its NTDS settings. 6. 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.

Check the status of the shared SYSVOL


This procedure involves checking Event Viewer to make sure that the File Replication service is started properly and then ensuring that the SYSVOL and Net Logon shared folders are created. Note You do not need to perform this procedure on every replication partner, but you need to perform it enough times to be confident that the shared system volumes on the replication partners are healthy. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To check the status of the shared SYSVOL 1. Open Event Viewer. 2. In the Event Viewer tree, click File Replication Service to display the FRS events. 3. 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 has started successfully. Event 13516 indicates that the service is started, the folders are shared, and the domain controller is functional. 4. 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 Net Logon and SYSVOL. 5. At a command prompt, type dcdiag /test:netlogons and press ENTER. 6. 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 Net Logon and SYSVOL shared folders.

Verify replication with other domain controllers


The tests performed in this procedure 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To verify replication is functioning 1. Open a Command Prompt. 2. Type the following command, and then press Enter: dcdiag /test:replications Note For this set of tests, the /v option is available. However, it does not display any significant additional information. Messages indicate that the connectivity and replications tests passed. 3. To verify that the proper permissions are set for replication, type the following command and then press Enter: dcdiag /test:netlogons Messages indicate that the connectivity and netlogons tests passed.

Gather the SYSVOL path information


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. For more information about the folder structure and the relationships between the folders and

the path information stored in the registry and the SYSVOL directory itself see Introduction to Administering SYSVOL. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. Use the procedures below to locate the system volume path information and record the current values in the following table. To relocate the staging area, record the information for rows 2 and 5. Note To restore and rebuild SYSVOL, you will need the information from the domain controller that you are repairing recorded in rows 1, 2, and 3. Use the junctions located on the domain controller that you are copying from the SYSVOL folder structure to record the current value for rows 4 and 5. The new values for rows 4 and 5 are based on the domain controller that you are repairing. Parameter 1 2 3 4 5 fRSRootPath fRSStagingPath Sysvol parameter in registry Sysvol junction Staging junction Current Value New Value

To gather the system volume path information


fRSRootPath and fRSStagingPath 1. Click Start, click Run, type adsiedit.msc, and then press Enter. 2. Double-click Domain [computername] (where computername is the name of this domain controller). Verify that the Domain expands to display the domain component (DC=) folder. 3. Click the domain component to display the containers and OUs in the details pane.

4. Double-click OU=Domain Controllers to display the containers that represent the domain controllers. 5. Double-click the container that represents this domain controller (CN=computername) to display more containers. 6. Click the CN=NTFRS Subscriptions container. 7. In the details pane, right-click CN=Domain System Volume, and then click Properties. 8. Ensure that Show mandatory attributes is selected. Select it if it is not. 9. In Attributes, locate fRSRootPath and fRSStagingPath and record the current values in the table above. 10. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 11. Click Cancel to close the dialog box. SYSVOL parameter in the registry 1. Click Start, click Run, type regedit and then press ENTER. 2. In Registry Editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Paramete rs. 3. Sysvol appears in the details pane. The current value is listed in the Data column. 4. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 5. Exit Registry Editor. SYSVOL junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name

(FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. Staging junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name (FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table.

Reset the File Replication service staging folder to a different logical drive
Use this procedure to reset the FRS Staging folder to a different logical drive. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory.

To reset the File Replication service staging folder to a different logical drive 1. Click Start, click Run, type adsiedit.msc, and then press ENTER. 2. Under Domain [computername], locate the NtFrs Subscriber object under the host computer account in Active Directory. The generic path for this attribute is: CN=Replica Set Name,CN=NTFRS Subscriptions,CN=Computername,DC=Domain Name,DC=COM. For example, to reset the staging path for the SYSVOL replica set of domain controller \\DC1 in the contoso.com domain, the distinguished name (also known as DN) path for the FrsStagingPath parameter is: CN=Domain System Volume (SYSVOL share), CN=NTFRS Subscriptions,CN=DC1,DC=CONTOSO,DC=COM Where (when you read the distinguished name path from right to left): DC=CONTOSO,DC=COM is the domain hosting the computer account. CN=DC1 is the host computer account in the domain naming context (NC). CN=NTFRS Subscriptions is the NtfrsSubscriber object that holds the FrsStagingPath parameter. CN=Domain System Volume (SYSVOL share) is the FRS subscriber object. 3. Right-click the CN=Domain System Volume container, and click Properties. 4. Ensure that the Show mandatory attributes check box is selected. Select it if it is not. 5. In Attributes, click fRSStagingPath, and then click Edit. The current value appears in the Value box in the String Attribute Editor dialog box. 6. Enter the path to the new location for the FRS Staging folder in the Value box and click OK. 7. Click OK to close Properties. 8. To make sure that the staging path has been updated in the registry: a. Click Start, click Run, and type regedit on the server where you are changing the staging path and then press ENTER. b. Locate the following subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets c. Double-click Replica Sets. All replica sets are displayed as a GUID.

d. To locate the replica set you are updating the staging area for, click a GUID and, in the details pane, find the Replica Set Name. Repeat until you find the correct replica set. e. After you locate the correct GUID and replica set name, right-click Replica Set Stage and

then click Modify. f. In the Value data box, type the new staging area path, and then click OK.

When the service detects a change in the staging path, event ID 13563 is logged with a series of self-explanatory steps on how to proceed: Event Type: Warning Event Source: NtFrs Event Category: None Event ID: 13563 Date: 3/6/2005 Time: 7:13:01 PM User: N/A Computer: <Computer name> Description: The File Replication service has detected that the staging path for the replica set DOMAIN SYSTEM VOLUME (SYSVOL SHARE) has changed. Current staging path = E:\Windows\Sysvol\Staging\Domain New staging path = E:\Frsstage The service will start using the new staging path after it restarts. The service is set to restart after every restart. It is recommended that you manually restart the service to prevent loss of data in the Staging folder. To manually restart the service do the following: [1] Run "net stop ntfrs" or use the Services snap-in to stop File Replication service. [2] Move all the staging files corresponding to replica set DOMAIN SYSTEM VOLUME (SYSVOL SHARE) to the new staging location. If more than one replica set are sharing the current staging folder then it is safer to copy the staging files to the new staging folder. [3] Run "net start ntfrs" or use the Services snap-in to start File Replication service, followed by "net start ntfrs". 9. To perform steps 1 through 3 in the event message, open a Command Prompt. 10. Type the following command and then press ENTER: net stop ntfrs 11. Move all the staging files corresponding to replica set DOMAIN SYSTEM VOLUME (SYSVOL

SHARE) to the new staging location. If more than one replica set is sharing the current Staging folder, then it is safer to copy the staging files to the new Staging folder. 12. At a command prompt type the following command and then press ENTER: net start ntfrs Microsoft recommends that you follow step 11 (step 2 in the preceding event message) because the FRS Staging folder may contain thousands or tens of thousands of files in the original Staging folder, all of which may be destined for one or more downstream partners. In Windows Explorer, you can view the files in the staging folder. On the Folder Options menu, click the View tab, and then click to select the Show hidden files and folders check box. Copy the files to the new Staging folder, and then follow the remaining steps in the event log message.

Relocating SYSVOL Manually


If you must move the entire system volume, not just the Staging Area folder, then you can relocate the system volume manually. Because no utilities can automate this process, you must carefully move all folders and properly maintain the same level of security at the new location. You can also move SYSVOL with the Active Directory wizard, but this requires that you remove Active Directory from the domain controller and then reinstall Active Directory after SYSVOL has been moved. This should only be considered in extreme cases, and only when the domain controller is not running any other services or applications. Except where noted, perform these steps on the domain controller that contains the system volume that you want to move. Caution 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. This will cause additional replication traffic. Note that failure to reset permissions can result in unauthorized access to Group Policy objects and logon and logoff scripts. Task Requirements The following tools are required to perform the procedures for this task:

Active Directory Sites and Services (Administrative Tools) Event Viewer Windows Explorer Dcdiag.exe (Windows Support Tools) Regedit.exe ADSI Edit.msc (Windows Support Tools) Linkd.exe (Windows Server 2003 Resource Kit Tools) Net.exe Secedit.exe Notepad.exe

Note To create or update junctions, you need the Linkd.exe tool supplied with Windows Server 2003 Resource Kit Tools on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=16544. Linkd allows you to create, delete, update, and view the links that are stored in junction points. To complete this task, perform the following procedures: 1. Identify replication partners 2. Check the status of the shared SYSVOL 3. Verify replication with other domain controllers 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. Prepare a domain controller for nonauthoritative SYSVOL restart 10. Update security on the new SYSVOL 11. Start the File Replication service 12. Check the status of the shared SYSVOL

Identify replication partners


Use this procedure to examine the Connection objects for a domain controller and determine its replication partners. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To identify replication partners 1. Open Active Directory Sites and Services. 2. In the console tree, expand the Sites container to display the list of sites. 3. Double-click the site that contains the domain controller for which you want to determine Connection objects. Note If you do not know the site in which the domain controller is located, 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. 4. Expand the Servers folder to display the list of servers in that site. 5. Expand the name of your domain controller to display its NTDS settings. 6. 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.

Check the status of the shared SYSVOL


This procedure involves checking Event Viewer to make sure that the File Replication service is started properly and then ensuring that the SYSVOL and Net Logon shared folders are created.

Note You do not need to perform this procedure on every replication partner, but you need to perform it enough times to be confident that the shared system volumes on the replication partners are healthy. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To check the status of the shared SYSVOL 1. Open Event Viewer. 2. In the Event Viewer tree, click File Replication Service to display the FRS events. 3. 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 has started successfully. Event 13516 indicates that the service is started, the folders are shared, and the domain controller is functional. 4. 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 Net Logon and SYSVOL. 5. At a command prompt, type dcdiag /test:netlogons and press ENTER. 6. 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 Net Logon and SYSVOL shared folders.

Verify replication with other domain controllers


The tests performed in this procedure 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To verify replication is functioning 1. Open a Command Prompt. 2. Type the following command, and then press Enter: dcdiag /test:replications Note For this set of tests, the /v option is available. However, it does not display any significant additional information. Messages indicate that the connectivity and replications tests passed. 3. To verify that the proper permissions are set for replication, type the following command and then press Enter: dcdiag /test:netlogons Messages indicate that the connectivity and netlogons tests passed.

Gather the SYSVOL path information


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. For more information about the folder structure and the relationships between the folders and

the path information stored in the registry and the SYSVOL directory itself see Introduction to Administering SYSVOL. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. Use the procedures below to locate the system volume path information and record the current values in the following table. To relocate the staging area, record the information for rows 2 and 5. Note To restore and rebuild SYSVOL, you will need the information from the domain controller that you are repairing recorded in rows 1, 2, and 3. Use the junctions located on the domain controller that you are copying from the SYSVOL folder structure to record the current value for rows 4 and 5. The new values for rows 4 and 5 are based on the domain controller that you are repairing. Parameter 1 2 3 4 5 fRSRootPath fRSStagingPath Sysvol parameter in registry Sysvol junction Staging junction Current Value New Value

To gather the system volume path information


fRSRootPath and fRSStagingPath 1. Click Start, click Run, type adsiedit.msc, and then press Enter. 2. Double-click Domain [computername] (where computername is the name of this domain controller). Verify that the Domain expands to display the domain component (DC=) folder. 3. Click the domain component to display the containers and OUs in the details pane.

4. Double-click OU=Domain Controllers to display the containers that represent the domain controllers. 5. Double-click the container that represents this domain controller (CN=computername) to display more containers. 6. Click the CN=NTFRS Subscriptions container. 7. In the details pane, right-click CN=Domain System Volume, and then click Properties. 8. Ensure that Show mandatory attributes is selected. Select it if it is not. 9. In Attributes, locate fRSRootPath and fRSStagingPath and record the current values in the table above. 10. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 11. Click Cancel to close the dialog box. SYSVOL parameter in the registry 1. Click Start, click Run, type regedit and then press ENTER. 2. In Registry Editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Paramete rs. 3. Sysvol appears in the details pane. The current value is listed in the Data column. 4. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 5. Exit Registry Editor. SYSVOL junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name

(FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. Staging junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name (FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table.

Stop the File Replication service


Use this procedure to stop the File Replication service. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To stop the File Replication service 1. Open a Command Prompt.

2. Type the following command and then press Enter: net stop ntfrs

Create the SYSVOL folder structure


Use this procedure to create the SYSVOL folder structure. The %systemroot%\SYSVOL folder is at 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To create the SYSVOL folder structure 1. In Windows Explorer, navigate to the folder that represents your current Windows system volume. By default, this is the %systemroot%\SYSVOL folder. 2. Right-click the SYSVOL folder, and then click Copy. 3. 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. 4. Verify that the folder structure was copied correctly. Compare the new folder structure to the original by opening a command prompt, typing the following command and pressing Enter to list the contents of the folders: dir /s Ensure that all folders exist. If any folders are missing at the new location (such as \scripts), then recreate them.

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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To set the SYSVOL path 1. Click Start, click Run, type regedit and then press ENTER. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Paramete rs. 3. Right-click SysVol and click Modify. 4. In the Value data box, in the Edit String dialog box, enter the new path, including the drive letter and click OK. 5. Close 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.

Set the staging area path


Use this procedure to modify the fRSStagingPath parameter 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.

Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To set the staging area path 1. Double-click Domain [computername] (where computername is the name of this domain controller). Verify that the Domain expands to display the domain component (DC=) folder. 2. Click the domain component to display the containers and OUs in the details pane. 3. Double-click OU=Domain Controllers to display the containers that represent the domain controllers. 4. Double-click the container that represents this domain controller (CN=computername) to display more containers. 5. Click the CN=NTFRS Subscriptions container. 6. In the details pane, right-click CN=Domain System Volume, and then click Properties. 7. Ensure that Show mandatory attributes is selected. Select it if it is not. 8. In Attributes, click fRSStagingPath, and then click Edit. The current value appears in the Value box in the String Attribute Editor dialog box. 9. In the Value 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), including the drive letter and click OK. 10. Close ADSI Edit. 11. Open a Command Prompt. 12. Change the directory to %systemroot%\SYSVOL\staging areas. 13. Type the following command to list the contents of the directory and then press ENTER: dir Verify that <JUNCTION> appears in the DIR output. 14. Update the junction so that it points to the new location by typing the following command and then pressing ENTER: linkd junctionname newpath

where newpath specifies the same value that you entered for fRSStagingPath earlier.

Prepare a domain controller for nonauthoritative SYSVOL restart


Initiate a nonauthoritative restart 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 nonauthoritative restart of SYSVOL when the domain controller is restarted. Separate entries exist for global and replica-set-specific BurFlags, as follows: To initiate a nonauthoritative restart 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 If other replica sets are represented on the domain controller and you want to update 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. 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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory.

To prepare a domain controller for nonauthoritative SYSVOL restart 1. Click Start, click Run, type regedit and then click OK. 2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters 3. Expand Parameters. 4. Modify one of the BurFlags entries as follows: To modify the global BurFlags entry: a. Expand Backup/Restore and then click Process at Startup. b. In the details pane, right-click BurFlags and click Modify. c. In the Value data box, type D2 hexadecimal or 210 decimal.

d. Click OK and close Registry Editor. To modify the replica-set-specific BurFlags entry: a. Expand both Cumulative Replica Sets and Replica Sets. b. Match the GUID under Replica Sets to the identical GUID under Cumulative Replica Sets, and click the matching GUID under Cumulative Replica Sets. c. In the details pane, right click BurFlags and click Modify.

d. In the Value data box, type D2 hexadecimal or 210 decimal. e. Click OK and close Registry Editor.

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. Caution 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. Administrative Credentials

To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To update security on the new SYSVOL 1. Click Start, click Run, type regedit and then press ENTER. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Netlogon\Parameters. Note the path stored under SysVol. 3. In Control Panel, double-click System. 4. On the Advanced tab, click Environment Variables. 5. Under System Variables, click New. 6. For Variable name, type sysvol. 7. For Variable value, type the path that you noted in step 2. 8. Click OK twice. Click OK again to close Properties.

9. 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)" Use this file to apply the security settings to the new SYSVOL folders. Save this file as Sysvol.inf.

Note Do not include a space after (A;CIOI;GRGX;;;SO), (A;CIOI;GRGX;;;AU), or (A;CIOI;GA;;;SY). 10. 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 the directory to the folder where you saved the Sysvol.inf file. 11. Type the following command all on one line and then press ENTER: SECEDIT /Configure /cfg sectemplatepath\sysvol.inf /db sectemplatepath\sysvol.db /overwrite where sectemplatepath specifies the path to where you saved Sysvol.inf.

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. Administrative Credentials To perform this procedure you must be a member of the Domain Admins group in Active Directory. To start the File Replication service 1. Open a Command Prompt. 2. Type the following command, and then press Enter: net start ntfrs 3. 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.

Updating 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 in order to solve this problem. To change the path for the system volume, you need to 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 File Replication service so it can reinitialize with the new values. Task Requirements The following tools are required to perform the procedures for this task: ADSI Edit.msc Net.exe Regedit.exe Linkd.exe

To complete this task, perform the following procedures in order: 1. Gather the SYSVOL path information 2. Stop the File Replication service 3. Set the SYSVOL path 4. Set the staging area path 5. Start the File Replication service

Gather the SYSVOL path information


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. For more information about the folder structure and the relationships between the folders and

the path information stored in the registry and the SYSVOL directory itself see Introduction to Administering SYSVOL. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. Use the procedures below to locate the system volume path information and record the current values in the following table. To relocate the staging area, record the information for rows 2 and 5. Note To restore and rebuild SYSVOL, you will need the information from the domain controller that you are repairing recorded in rows 1, 2, and 3. Use the junctions located on the domain controller that you are copying from the SYSVOL folder structure to record the current value for rows 4 and 5. The new values for rows 4 and 5 are based on the domain controller that you are repairing. Parameter 1 2 3 4 5 fRSRootPath fRSStagingPath Sysvol parameter in registry Sysvol junction Staging junction Current Value New Value

To gather the system volume path information


fRSRootPath and fRSStagingPath 1. Click Start, click Run, type adsiedit.msc, and then press Enter. 2. Double-click Domain [computername] (where computername is the name of this domain controller). Verify that the Domain expands to display the domain component (DC=) folder. 3. Click the domain component to display the containers and OUs in the details pane.

4. Double-click OU=Domain Controllers to display the containers that represent the domain controllers. 5. Double-click the container that represents this domain controller (CN=computername) to display more containers. 6. Click the CN=NTFRS Subscriptions container. 7. In the details pane, right-click CN=Domain System Volume, and then click Properties. 8. Ensure that Show mandatory attributes is selected. Select it if it is not. 9. In Attributes, locate fRSRootPath and fRSStagingPath and record the current values in the table above. 10. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 11. Click Cancel to close the dialog box. SYSVOL parameter in the registry 1. Click Start, click Run, type regedit and then press ENTER. 2. In Registry Editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Paramete rs. 3. Sysvol appears in the details pane. The current value is listed in the Data column. 4. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 5. Exit Registry Editor. SYSVOL junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name

(FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. Staging junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name (FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table.

Stop the File Replication service


Use this procedure to stop the File Replication service. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To stop the File Replication service 1. Open a Command Prompt.

2. Type the following command and then press Enter: net stop ntfrs

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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To set the SYSVOL path 1. Click Start, click Run, type regedit and then press ENTER. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Paramete rs. 3. Right-click SysVol and click Modify. 4. In the Value data box, in the Edit String dialog box, enter the new path, including the drive letter and click OK. 5. Close 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.

Set the staging area path


Use this procedure to modify the fRSStagingPath parameter 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To set the staging area path 1. Double-click Domain [computername] (where computername is the name of this domain controller). Verify that the Domain expands to display the domain component (DC=) folder. 2. Click the domain component to display the containers and OUs in the details pane. 3. Double-click OU=Domain Controllers to display the containers that represent the domain controllers. 4. Double-click the container that represents this domain controller (CN=computername) to display more containers. 5. Click the CN=NTFRS Subscriptions container. 6. In the details pane, right-click CN=Domain System Volume, and then click Properties. 7. Ensure that Show mandatory attributes is selected. Select it if it is not. 8. In Attributes, click fRSStagingPath, and then click Edit. The current value appears in the Value box in the String Attribute Editor dialog box. 9. In the Value 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), including the drive letter and click OK. 10. Close ADSI Edit. 11. Open a Command Prompt. 12. Change the directory to %systemroot%\SYSVOL\staging areas. 13. Type the following command to list the contents of the directory and then press

ENTER: dir Verify that <JUNCTION> appears in the DIR output. 14. Update the junction so that it points to the new location by typing the following command and then pressing ENTER: linkd junctionname newpath where newpath specifies the same value that you entered for fRSStagingPath earlier.

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. Administrative Credentials To perform this procedure you must be a member of the Domain Admins group in Active Directory. To start the File Replication service 1. Open a Command Prompt. 2. Type the following command, and then press Enter: net start ntfrs 3. 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.

Restoring and Rebuilding SYSVOL


If your efforts to move SYSVOL or perform certain maintenance tasks fail, 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. Use these procedures only if you are working on a domain controller that does not have a functional SYSVOL. Task Requirements The following tools are required to perform the procedures for this task: Active Directory Sites and Services Event Viewer Dcdiag.exe ADSIEdit.msc Net.exe Regedit.exe Windows Explorer Linkd.exe Ultrasound for monitoring

To complete this task, perform the following procedures in order: 1. Identify replication partners 2. Check the status of the shared SYSVOL 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 replication with other domain controllers 4. Restart the domain controller in Directory Services Restore Mode locally 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 nonauthoritative SYSVOL restart 8. Import the SYSVOL folder structure 9. Start the File Replication service 10. Check the status of the shared SYSVOL

Identify replication partners


Use this procedure to examine the Connection objects for a domain controller and determine its replication partners. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To identify replication partners 1. Open Active Directory Sites and Services. 2. In the console tree, expand the Sites container to display the list of sites. 3. Double-click the site that contains the domain controller for which you want to determine Connection objects. Note If you do not know the site in which the domain controller is located, 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. 4. Expand the Servers folder to display the list of servers in that site. 5. Expand the name of your domain controller to display its NTDS settings. 6. 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.

Check the status of the shared SYSVOL


This procedure involves checking Event Viewer to make sure that the File Replication service is started properly and then ensuring that the SYSVOL and Net Logon shared folders are created. Note You do not need to perform this procedure on every replication partner, but you need to perform it enough times to be confident that the shared system volumes on the replication partners are healthy. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To check the status of the shared SYSVOL 1. Open Event Viewer. 2. In the Event Viewer tree, click File Replication Service to display the FRS events. 3. 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 has started successfully. Event 13516 indicates that the service is started, the folders are shared, and the domain controller is functional. 4. 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 Net Logon and SYSVOL. 5. At a command prompt, type dcdiag /test:netlogons and press ENTER. 6. 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 Net Logon and SYSVOL shared folders.

Verify replication with other domain controllers


The tests performed in this procedure 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To verify replication is functioning 1. Open a Command Prompt. 2. Type the following command, and then press Enter: dcdiag /test:replications Note For this set of tests, the /v option is available. However, it does not display any significant additional information. Messages indicate that the connectivity and replications tests passed. 3. To verify that the proper permissions are set for replication, type the following command and then press Enter: dcdiag /test:netlogons Messages indicate that the connectivity and netlogons tests passed.

Restart the domain controller in Directory Services Restore Mode locally


If you have physical access to a domain controller, you can restart the domain controller in Directory Services Restore Mode locally. Restarting in Directory Services Restore Mode takes the domain controller offline. In this mode, the server is not functioning as a domain controller.

When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restart the domain controller in Directory Services Restore Mode locally 1. Restart the domain controller. 2. When the screen for selecting an operating system appears, press F8. 3. On the Windows Advanced Options menu, select Directory Services Restore Mode. 4. When you are prompted, log on as the local administrator.

See Also
Restart the domain controller in Directory Services Restore Mode Remotely

Gather the SYSVOL path information


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. For more information about the folder structure and the relationships between the folders and the path information stored in the registry and the SYSVOL directory itself see Introduction to Administering SYSVOL. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory.

Use the procedures below to locate the system volume path information and record the current values in the following table. To relocate the staging area, record the information for rows 2 and 5. Note To restore and rebuild SYSVOL, you will need the information from the domain controller that you are repairing recorded in rows 1, 2, and 3. Use the junctions located on the domain controller that you are copying from the SYSVOL folder structure to record the current value for rows 4 and 5. The new values for rows 4 and 5 are based on the domain controller that you are repairing. Parameter 1 2 3 4 5 fRSRootPath fRSStagingPath Sysvol parameter in registry Sysvol junction Staging junction Current Value New Value

To gather the system volume path information


fRSRootPath and fRSStagingPath 1. Click Start, click Run, type adsiedit.msc, and then press Enter. 2. Double-click Domain [computername] (where computername is the name of this domain controller). Verify that the Domain expands to display the domain component (DC=) folder. 3. Click the domain component to display the containers and OUs in the details pane. 4. Double-click OU=Domain Controllers to display the containers that represent the domain controllers. 5. Double-click the container that represents this domain controller (CN=computername) to display more containers. 6. Click the CN=NTFRS Subscriptions container.

7. In the details pane, right-click CN=Domain System Volume, and then click Properties. 8. Ensure that Show mandatory attributes is selected. Select it if it is not. 9. In Attributes, locate fRSRootPath and fRSStagingPath and record the current values in the table above. 10. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 11. Click Cancel to close the dialog box. SYSVOL parameter in the registry 1. Click Start, click Run, type regedit and then press ENTER. 2. In Registry Editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Paramete rs. 3. Sysvol appears in the details pane. The current value is listed in the Data column. 4. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. 5. Exit Registry Editor. SYSVOL junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name (FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure

discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table. Staging junction 1. Open a Command Prompt. 2. Change the 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. 3. At the command prompt, type dir. Verify that the fully qualified domain name (FQDN) is listed as type <JUNCTION>. 4. 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. 5. Record the current value in table above. Based on the folder structure discussed in detail in Introduction to Administering SYSVOL and the new location, record the new path value for this parameter in the table.

Stop the File Replication service


Use this procedure to stop the File Replication service. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To stop the File Replication service 1. Open a Command Prompt. 2. Type the following command and then press Enter: net stop ntfrs

Prepare a domain controller for nonauthoritative SYSVOL restart


Initiate a nonauthoritative restart 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 nonauthoritative restart of SYSVOL when the domain controller is restarted. Separate entries exist for global and replica-set-specific BurFlags, as follows: To initiate a nonauthoritative restart 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 If other replica sets are represented on the domain controller and you want to update 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. 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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To prepare a domain controller for nonauthoritative SYSVOL restart 1. Click Start, click Run, type regedit and then click OK. 2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters

3. Expand Parameters. 4. Modify one of the BurFlags entries as follows: To modify the global BurFlags entry: a. Expand Backup/Restore and then click Process at Startup. b. In the details pane, right-click BurFlags and click Modify. c. In the Value data box, type D2 hexadecimal or 210 decimal.

d. Click OK and close Registry Editor. To modify the replica-set-specific BurFlags entry: a. Expand both Cumulative Replica Sets and Replica Sets. b. Match the GUID under Replica Sets to the identical GUID under Cumulative Replica Sets, and click the matching GUID under Cumulative Replica Sets. c. In the details pane, right click BurFlags and click Modify.

d. In the Value data box, type D2 hexadecimal or 210 decimal. e. Click OK and close Registry Editor.

Import the SYSVOL folder structure


Use this procedure to copy the SYSVOL folder structure from another domain controller. The %systemroot%\SYSVOL folder is at 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 in order 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.

Caution 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To import the SYSVOL folder structure 1. Open Windows Explorer. 2. Navigate to the existing %systemroot%\SYSVOL folder that you are rebuilding and delete it. 3. 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. 4. Once you are connected to the Admin$ share point, verify that a folder labeled SYSVOL appears. Right-click the SYSVOL folder, and click Copy. 5. 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. 6. Verify that the original SYSVOL folder and a new folder labeled Copy of SYSVOL both appear. Right-click Copy of SYSVOL and click Rename. Type SYSVOL2 and press ENTER. 7. Open a command prompt. Change to the drive letter that represents the connection to the remote domain controller where you created the SYSVOL2 folder. 8. Change the directory to SYSVOL2\sysvol. 9. Type dir and press ENTER. Verify that <JUNCTION> appears in the Dir output and is followed by the name of the domain. 10. 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 4 of the table in Gather the SYSVOL path information. Press ENTER. 11. 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 the 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. 12. 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 5 of Table 1 while gathering system volume path information. Press ENTER. 13. At the command prompt, change back to the %systemroot% for the domain controller that you are repairing. 14. From the command prompt, use the Xcopy command 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. 15. 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 type dir to list the contents of the folders. Ensure that all folders exist. 16. Remove the SYSVOL2 folder that you created on the remote domain controller. 17. 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. 18. Restart the domain controller in normal mode.

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. Administrative Credentials To perform this procedure you must be a member of the Domain Admins group in Active Directory. To start the File Replication service 1. Open a Command Prompt. 2. Type the following command, and then press Enter: net start ntfrs 3. 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.

Administering the Global Catalog


This guide provides information for administering the Active Directory Global Catalog in the Microsoft Windows Server 2003 operating system. In this guide Introduction to Administering the Global Catalog Managing the Global Catalog

Acknowledgements Published: March 2005 Applies to: Windows Server 2003 SP1 Produced by: Microsoft Windows Server User Assistance team Writer: Mary Hillman

Editor: Jim Becker

Introduction to Administering the Global Catalog


Designate global catalog servers in sites to accommodate forest-wide directory searching and to facilitate domain client logons when universal groups are available (that is, when a domain has a domain functional level of Windows Server 2003 or Windows 2000 native). When universal groups are available in the domain, a domain controller must be able to locate a global catalog server to process a logon request.

Global Catalog Placement


Placement of global catalog servers in sites is a deployment task when you initially deploy your forest. As your forest grows, you might need to add more global catalog servers. 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, configure half of all domain controllers in a site to be global catalog servers if the site contains more than three domain controllers. If your deployment uses only a single domain, configure all domain controllers as global catalog servers. In a singledomain 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 the same 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


A global catalog server is available to directory clients when it is locatable as a global catalog server in Domain Name System (DNS). Several conditions must be met before the global catalog server is ready to serve clients. These conditions are divided into seven levels (numbered 0 to 6) of readiness called occupancy levels. At each level, a specific degree of synchronization must be achieved before moving to the next level. By default, domain controllers running Windows Server 2003 require all levels to be reached before the global catalog is ready for use. At level 6, all partial, read-only directory partitions have been successfully replicated to the global catalog server. When the requirements of all occupancy levels have been satisfied, the Net Logon service on the global catalog server registers DNS service (SRV) resource records that identify the domain controller as a global catalog server in the site and in the forest. In summary, a global catalog server is 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 catalogspecific SRV resource records. At this point, the global catalog server begins accepting queries on ports 3268 and 3269.

Global Catalog Removal


When you remove the global catalog, the domain controller immediately stops advertising in DNS as a global catalog server. The KCC gradually removes the read-only replicas from the domain controller. On domain controllers running Windows Server 2003, the global

catalog partial, read-only directory partitions are removed in the background, receiving a low priority so that high-priority services are not interrupted. One reason that you might want to remove the global catalog from a domain controller is the availability of universal group membership caching in Windows Server 2003, which might eliminate the requirement for a global catalog server in a particular site. Minimum hardware requirements for global catalog servers depend upon the numbers of users in the site. For disk space requirements and directory database storage guidelines, see "Assessing Disk Space and Memory Requirements" in Designing and Deploying Directory and Security Services on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=45434).

See Also
Windows Server 2003 Technical Reference

Managing the Global Catalog


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. The following tasks for managing the global catalog are described in this objective: Configuring a Global Catalog Server Determining Global Catalog Readiness Removing the Global Catalog

Configuring a Global Catalog Server


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. Task Requirements

The following tools are required to perform the procedures for this task: Active Directory Sites and Services Repadmin.exe Dcdiag.exe

To complete this task, perform the following procedures: Note Some procedures are performed only when you are configuring the first global catalog server in a site. 1. Determine whether a domain controller is a global catalog server 2. Designate a domain controller to be a global catalog server 3. Monitor global catalog replication progress 4. Verify successful replication to a domain controller

Determine whether a domain controller is 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group in Active Directory. To determine whether a domain controller is a global catalog server 1. Open Active Directory Sites and Services. 2. In the console tree, 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. 3. Right-click the NTDS Settings object, and then click Properties. 4. On the General tab, if the Global Catalog box is selected, the domain controller is designated as a global catalog server.

Designate a domain controller to be a global catalog server


Setting the Global Catalog check box designates a domain controller as a global catalog server and initiates the process of replicating all domains to the server. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in the domain where you are configuring the domain controller to be a global catalog server. To designate a domain controller to be a global catalog server 1. Open Active Directory Sites and Services. 2. In the console tree expand the Sites container, and then expand the site in which you are designating a global catalog server. 3. Expand the Servers container and then expand the Server object for the domain controller that you want to designate as a global catalog server. 4. Right-click the NTDS Settings object for the target server, and then click Properties. 5. Select the Global Catalog check box, and then click OK.

Monitor global catalog replication progress


Monitor inbound replication progress to see how many (percentage) of the partial read-only directory partitions in the forest have replicated to a new global catalog server. Note Exchange 2003 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, or after occupancy requirements are met. Administrative Credentials To perform this procedure you must be a member of the Domain Admins group in Active Directory. To monitor global catalog replication progress 1. Open a Command Prompt. 2. Type the following command and then press ENTER: dcdiag /v /s:servername| find "%" Value servername Description Specifies the name of the new global catalog server.

3. Repeat this command periodically to monitor progress. If the test shows no output, then replication has completed.

Determining Global Catalog Readiness


After replication of the partial domain directory partitions, the domain controller advertises as a global catalog server and begins accepting queries. 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. Determine if a domain controller is ready to begin advertising itself as a global catalog server using the procedures for this task. Task Requirements The following tools are required to perform the procedures for this task: Ldp.exe Nltest.exe

DNS snap-in

Note The global catalog server must be restarted after replication has completed and before readiness is determined. To complete this task, perform the following procedures: 1. Verify global catalog readiness 2. Verify global catalog DNS registrations

Verify global catalog readiness


When a global catalog server has satisfied replication requirements, the isGlobalCatalogReady rootDSE attribute is set to TRUE and the global catalog is ready to serve clients. Administrative Credentials To perform the following procedures you must be a member of the Domain Users group.

To verify global catalog readiness


Using the Windows interface Using a command prompt

Using the Windows interface 1. Click Start, click Run, type Ldp, and then click OK. 2. On the Connection menu, click Connect. 3. In the Connect box, type the name of the server whose global catalog readiness you want to verify. 4. In the Port box, if 389 is not showing, type 389. 5. If the Connectionless box is selected, clear it, and then click OK. 6. In the details pane, verify that the isGlobalCatalogReady attribute has a

value of TRUE. 7. On the Connection menu, click Disconnect, and then close Ldp.

Using a command prompt 1. Open a Command Prompt. 2. Type the following command and then press ENTER: nltest /server:servername /dsgetdc:domainname Value servername Description Specifies the name of the domain controller you have designated as a global catalog server. Specifies the name of the domain to which the server belongs.

domainname

3. In the Flags: line of the output, if GC appears, then the global catalog server has satisfied its replication requirements

Verify global catalog DNS registrations


To verify that a server is advertised as a global catalog server, verify the presence of DNS SRV resource records for the server. Restart the global catalog server prior to checking DNS registrations. Administrative Credentials To perform this procedure you must be a member of the Domain Users group. To verify global catalog DNS registrations 1. Open the DNS snap-in and connect to a domain controller in the forest root domain.

2. Expand Forward Lookup Zones and then expand the forest root domain. 3. Click the _tcp container. 4. 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.

Removing the Global Catalog


Removing the global catalog from a domain controller simply requires clearing the Global Catalog check box on the NTDS Settings object properties page. As soon as this is complete, the domain controller stops advertising itself as a global catalog server (Net Logon de-registers the global catalog-related records in DNS) and it immediately stops accepting LDAP requests over ports 3268 and 3269. Task Requirements The following tool is required to perform the procedures for this task: Active Directory Sites and Services

To complete this task, perform the following procedures: 1. Clear the global catalog setting 2. Monitor global catalog removal in Event Viewer

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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the global catalog server. To clear the global catalog setting 1. Open Active Directory Sites and Services.

2. Expand the Sites container, and then expand the site from which you are removing a global catalog server. 3. Expand the Servers container and then expand the Server object for the domain controller that you want to remove as a global catalog server. 4. Right-click the NTDS Settings object for the target server, and then click Properties. 5. If the Global Catalog check box is selected, clear the check box, and then click OK.

Monitor global catalog removal in Event Viewer


To verify that the global catalog has been removed from a domain controller, monitor Event Viewer. The KCC logs Event 1268, when the global catalog has been successfully removed. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To monitor global catalog removal in Event Viewer 1. Click Start, point to Programs, Administrative Tools, and click Event Viewer. 2. Right-click Event Viewer (Local), and then click Connect to another computer. 3. 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. 4. Under Event Viewer, click Directory Services log. 5. Look for NTDS KCC event ID 1268, which indicates that the global catalog is removed from the local machine.

Administering Operations Master Roles


This guide provides information for administering Active Directory operations master roles in the Microsoft Windows Server 2003 operating system. In this guide Introduction to Administering Operations Master Roles Managing Operations Master Roles

Acknowledgements Published: March 2005 Applies to: Windows Server 2003 Produced by: Microsoft Windows Server User Assistance team Writer: Shala Brandolini Editor: Jim Becker

Introduction to Administering Operations Master Roles


Operations masters keep the directory functioning properly by performing specific tasks that no other domain controllers are permitted to perform. 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. It also processes all password updates for clients not running Active Directoryenabled client software, plus any other directory write operations. The relative identifier (RID) master. The RID master allocates RID pools to all domain controllers to ensure that new security principals can be created with a unique identifier. The infrastructure master. The infrastructure master for a given domain maintains a list of the security principals for any linked-value attributes. In addition to the three domain-level operations 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 and application partitions to and from the forest. To perform these functions, the domain controllers hosting these operations master roles must be consistently available and be located in areas where network reliability is high. Careful placement of your operations masters becomes more important as you add more domains and sites to build your forest.

Guidelines for Role Placement


By improperly placing operations master role holders, you might prevent clients from changing their passwords or being able 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 function improperly. Other improper configurations can increase administrative overhead. 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 operations 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 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. 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. Because all clients prior to Active Directory 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 that 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. The infrastructure master updates the names of security principals for any domain-named linked attributes. For example, if a user from one domain is a member of a group in a second domain and the users name is changed in the first domain, then the second domain is not notified that the users name must be updated in the groups 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 principals 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. 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. 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. Again, clients prior to Active Directory 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 clients and domain controllers prior to Active Directory, you might need to reduce the workload of the PDC emulator. If a domain controller begins to indicate that it is overloaded and its performance is affected, you can reconfigure the environment so that some tasks are performed by other, less-used domain controllers. By adjusting the domain controllers 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 controllers priority in the DNS environment so that 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.

Guidelines for 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. Reasons for moving the operations master role(s) include inadequate service performance, failure or decommission of a domain controller hosting an operations master role, or if dictated by configuration changes made by an administrator. Inadequate level of service 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 Directoryenabled 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 operations roles to another, more powerful domain controller. Alternately, 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 operations master 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 downtime. Decommissioning of the domain controller Before permanently taking a domain controller offline, transfer any operations master roles held by the domain controller to another domain controller. 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. 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 operations master roles in order to keep them in a particular site. You can reassign an operations master role by transfer or, as a last resort, by seizure. 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.

Managing Operations Master Roles


Operations masters keep the directory functioning properly by performing specific tasks that no other domain controllers are permitted to perform. The following tasks for managing operations master roles are described in this objective: Designating a standby operations master Transferring an operations master role Seizing an operations master role Reducing the workload on the PDC emulator master

Designating a standby operations master


A standby operations master is a domain controller that you identify as the computer that assumes the operations master role if the original computer fails. 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. 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 a 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. 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 in Introduction to Administering Operations Master Roles. 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. Task Requirements

The following tools are required to perform the procedures for this task: Active Directory Sites and Services Repadmin.exe

To complete this task, perform the following procedures: 1. Determine whether a domain controller is a global catalog server 2. Create a connection object on the current operations master 3. Create a connection object on the standby operations master 4. Verify successful replication to a domain controller

Determine whether a domain controller is 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group in Active Directory. To determine whether a domain controller is a global catalog server 1. Open Active Directory Sites and Services. 2. In the console tree, 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. 3. Right-click the NTDS Settings object, and then click Properties. 4. On the General tab, if the Global Catalog box is selected, the domain controller is designated as a global catalog server.

Create a connection object on the current operations master


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. To determine the current operations master role holders, see View the current operations master role holders. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To create a connection object on the current operations master 1. Open Active Directory Sites and Services. 2. Expand the site name in which the standby operations master is located to display the Servers folder. 3. Expand the Servers folder to see a list of the servers in that site. 4. Expand the name of the server that is currently hosting the operations master role to display its NTDS Settings. 5. Right-click NTDS Settings, click New, and then click Connection. 6. In the Find Domain Controllers dialog box, select the name of the standby operations master, and then click OK. 7. 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 connection object on the standby operations master


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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To create a Connection object on the standby operations master 1. Open Active Directory Sites and Services. 2. Expand the site name in which the standby operations master is located to display the Servers folder. 3. Expand the Servers folder to see a list of the servers in that site. 4. Expand the name of the server that you want to be the standby operations master to display its NTDS Settings. 5. Right-click NTDS Settings, click New, and then click Connection. 6. In the Find Domain Controllers dialog box, select the name of the current role holder, and then click OK. 7. In the New Object-Connection dialog box, enter an appropriate name for the Connection object or accept the default name, and click OK.

Verify successful replication to a domain controller


You can use the repadmin /showrepl command to verify successful replication to a specific domain controller. If you are not running Repadmin on the domain controller whose

replication you are checking, you can specify a destination domain controller in the command. Repadmin lists INBOUND NEIGHBORS for the current or specified domain controller. INBOUND NEIGHBORS shows the 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 replication succeeded or not, as follows: Last attempt @ YYYY-MM-DD HH:MM.SS was successful. Last attempt @ [Never] was successful.

If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the destination domain controller. To verify successful replication to a domain controller 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl servername /u:domainname\username /pw:* Term servername domainname Definition Specifies the name of the destination domain controller. Specifies the single-label name of the domain of the destination domain controller. (You do not have to use a fully qualified Domain Name System (DNS) name.) Specifies the name of an administrative account in that domain.

username

3. When you are prompted for a password, type the password for the user account that you provided, and then press ENTER. You can also use Repadmin to generate the details of replication to and from all replication partners in a spreadsheet. The spreadsheet displays data in the following columns:

Showrepl_COLUMNS Destination DC Site Destination DC Naming Context Source DC Site Source DC Transport Type Number of Failures Last Failure Time Last Success Time Last Failure Status The following procedure shows how to create this spreadsheet and set column headers for improved readability. To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl * /csv >showrepl.csv 3. Open Microsoft Excel. 4. On the File menu, click Open, navigate to showrepl.csv, and then click Open. 5. Hide or delete column A as well as the Transport Type column, as follows: 6. Select a column that you want to hide or delete. To hide the column, on the Format menu, click Column, and then click Hide. Or To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row, and then, on the Window menu, click Freeze Panes. 8. Select the entire spreadsheet. On the Data menu, click Filter, and then click

AutoFilter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the down arrow, and then click Custom. 11. In the Custom AutoFilter dialog box, under Show rows where, click does not contain. In the adjacent text box, type del to eliminate from view the results for deleted domain controllers. 12. Repeat step 10 for the Last Failure Time column, but use the value does not equal, and type the value 0. 13. Resolve replication failures. The last successful attempt should agree with the replication schedule for intersite replication, or the attempt should be within the last hour for intrasite replication. If Repadmin reports any of the following conditions, see Troubleshooting Active Directory Replication Problems: The last successful intersite replication was prior to the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful.

See Also
Troubleshooting Active Directory Replication Problems

Transferring an operations master role


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. The transfer of forest-level and domain-level operations master roles is performed as needed and is governed by the guidelines for placing operations master roles. Before you transfer an operations master role, 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. 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. Transferring to a standby ops 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. Transferring an ops master role when no standby 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. In addition, you must determine whether the domain controller intended to assume an operations master role is a global catalog server. The infrastructure master for each domain must not host the global catalog. Task Requirements The following tools are required to perform the procedures for this task: Repadmin.exe Active Directory Sites and Services Active Directory Domains and Trusts Active Directory Schema snap-in Active Directory Users and Computers Ntdsutil.exe

To complete this task, perform the following procedures: 1. Verify successful replication to a domain controller

2. Determine whether a domain controller is a global catalog server 3. Install the Schema snap-in 4. Transfer the schema master 5. Transfer the domain naming master 6. Transfer the domain-level operations master roles 7. View the current operations master role holders

Verify successful replication to a domain controller


You can use the repadmin /showrepl command to verify successful replication to a specific domain controller. If you are not running Repadmin on the domain controller whose replication you are checking, you can specify a destination domain controller in the command. Repadmin lists INBOUND NEIGHBORS for the current or specified domain controller. INBOUND NEIGHBORS shows the 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 replication succeeded or not, as follows: Last attempt @ YYYY-MM-DD HH:MM.SS was successful. Last attempt @ [Never] was successful.

If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the destination domain controller. To verify successful replication to a domain controller 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl servername /u:domainname\username /pw:*

Term servername domainname

Definition Specifies the name of the destination domain controller. Specifies the single-label name of the domain of the destination domain controller. (You do not have to use a fully qualified Domain Name System (DNS) name.) Specifies the name of an administrative account in that domain.

username

3. When you are prompted for a password, type the password for the user account that you provided, and then press ENTER. You can also use Repadmin to generate the details of replication to and from all replication partners in a spreadsheet. The spreadsheet displays data in the following columns: Showrepl_COLUMNS Destination DC Site Destination DC Naming Context Source DC Site Source DC Transport Type Number of Failures Last Failure Time Last Success Time Last Failure Status The following procedure shows how to create this spreadsheet and set column headers for improved readability. To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt. 2. Type the following command, and then press ENTER:

repadmin /showrepl * /csv >showrepl.csv 3. Open Microsoft Excel. 4. On the File menu, click Open, navigate to showrepl.csv, and then click Open. 5. Hide or delete column A as well as the Transport Type column, as follows: 6. Select a column that you want to hide or delete. To hide the column, on the Format menu, click Column, and then click Hide. Or To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row, and then, on the Window menu, click Freeze Panes. 8. Select the entire spreadsheet. On the Data menu, click Filter, and then click AutoFilter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the down arrow, and then click Custom. 11. In the Custom AutoFilter dialog box, under Show rows where, click does not contain. In the adjacent text box, type del to eliminate from view the results for deleted domain controllers. 12. Repeat step 10 for the Last Failure Time column, but use the value does not equal, and type the value 0. 13. Resolve replication failures. The last successful attempt should agree with the replication schedule for intersite replication, or the attempt should be within the last hour for intrasite replication. If Repadmin reports any of the following conditions, see Troubleshooting Active Directory Replication Problems: The last successful intersite replication was prior to the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful.

See Also
Troubleshooting Active Directory Replication Problems

Determine whether a domain controller is 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group in Active Directory. To determine whether a domain controller is a global catalog server 1. Open Active Directory Sites and Services. 2. In the console tree, 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. 3. Right-click the NTDS Settings object, and then click Properties. 4. On the General tab, if the Global Catalog box is selected, the domain controller is designated as a global catalog server.

Install the Schema snap-in


Use this procedure to install the Active Directory Schema snap-in. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory. To install the Active Directory Schema snap-in 1. Open a Command Prompt.

2. Type the following command and then press ENTER: Regsvr32 schmmgmt.dll This command will register schmmgmt.dll on your computer. 3. Click Start, click Run, type mmc /a, and then click OK. 4. On the File menu, click Add/Remove Snap-in, and then click Add. 5. Under Available Standalone Snap-ins, double-click Active Directory Schema, click Close, and then click OK. 6. To save this console, on the File menu, click Save. 7. In Save in, point to the systemroot\system32 directory. 8. In File name, type schmmgmt.msc, and then click Save. 9. To create a shortcut on your Start menu: a. Right-click Start, click Open All Users, double-click the Programs folder, and then double-click the Administrative Tools folder. b. On the File menu, point to New, and then click Shortcut. c. In the Create Shortcut Wizard, in Type the location of the item, type schmmgmt.msc, and then click Next. d. On the Select a Title for the Program page, in Type a name for this shortcut, type Active Directory Schema, and then click Finish. Caution Modifying the schema is an advanced operation best performed by experienced programmers and system administrators. For detailed information about modifying the schema, see the Active Directory programmer's Guide at the Microsoft Web site.

Transfer the schema master


Use this procedure to transfer the schema operations master role. The schema master is a forest-wide operations master role. Before you can use the Active Directory Schema snapin for the first time, you must register it with the system. If you have not yet prepared the Active Directory Schema snap-in, see Install the Schema snap-in before you begin this procedure.

Note This procedure is performed by using the Microsoft Management Console (MMC), although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, type ? at the Ntdsutil.exe command prompt. Administrative Credentials To perform this procedure, you must be a Schema Administrator in Active Directory. Transfer the schema master 1. Open the Active Directory Schema snap-in. 2. In the console tree, right-click Active Directory Schema, and click Change Domain Controller. 3. In the Change Domain Controller dialog box, click Specify Name. Then, in the text box, type the name of the server to which you want to transfer the schema master role. Click OK. 4. In the console tree, right-click Active Directory Schema. Click Operations Master. The Change Schema Master box displays the name of the server that is currently holding the role. The targeted domain controller is listed in the second box. 5. Click Change. Click Yes to confirm your choice. The system confirms the operation. Click OK again to confirm that the operation succeeded. 6. Click Close to close the Change Schema Master dialog box. 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.

Transfer the domain naming master


Use this procedure to transfer the domain naming operations master role. The domain naming master is a forest-wide operations master role.

Note This procedure is performed by using the Microsoft Management Console (MMC), although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, type ? at the Ntdsutil.exe command prompt. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To transfer the domain naming master 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller. 3. Ensure that the proper domain name is entered in the Domain box. The available domain controllers from this domain are listed. 4. In the Name column, click the domain controller (to select it) to which you want to transfer the role. Click OK. 5. Right-click Active Directory Domains and Trusts, and then click Operations Master. 6. 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. 7. Click Change. To confirm the role transfer, click Yes. Click OK again to close the message box indicating the transfer took place. Click Close to close the Change Operations Master dialog box.

Transfer the domain-level operations master roles


Use this procedure to transfer the three domain-level operations master roles: 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.

Note 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To transfer a domain-level operations master role 1. Open Active Directory Users and Computers. 2. At the top of the console tree, right-click Active Directory Users and Computers. Click Connect to Domain Controller. 3. In the list of available domain controllers, click the name of the server to which you want to transfer the role, and then click OK. 4. At the top of the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Masters. The name of the current operations master role holder appears in the Operations master box. The name of the server to which you want to transfer the role appears in the lower box. 5. Click the tab for 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, and then click OK. 6. Repeat steps 4 and 5 for each role that you want to transfer.

View the current operations master role holders


Once an operations master role has been transferred, it should be verified that the transfer has occurred successfully throughout the domain. The change must be replicated to all relevant domain members in order to truly take effect. 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.

Administrative Credentials To perform this procedure, you must be logged on as a User or an Administrator. To view the current operations master role holder 1. Click Start, click Run, type ntdsutil, and then press ENTER. 2. At the ntdsutil: prompt, type roles and press ENTER. 3. At the fsmo maintenance: prompt, type connections and press ENTER. 4. 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). 5. After receiving confirmation of the connection, type quit and press ENTER to exit this menu. 6. At the fsmo maintenance: prompt, type select operation target and press ENTER. 7. 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 currently assigned to host each role. 8. 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.

Seizing an operations master role


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. It is for this reason that role seizure should be performed only as a last resort. 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 introduce 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 that was seized, the severity of duplicate operations master roles varies from no visible effect to potential corruption of the Active Directory database. Seize the operations master role to a domain controller that has the most recent updates from the current role holder to minimize the impact of the role seizure. Task Requirements Repadmin.exe Ntdsutil.exe

To complete this task, perform the following procedures: 1. Verify successful replication to a domain controller This needs to be the domain controller that will be seizing the role. 2. Seize the operations master role 3. View the current operations master role holders

Verify successful replication to a domain controller


You can use the repadmin /showrepl command to verify successful replication to a specific domain controller. If you are not running Repadmin on the domain controller whose replication you are checking, you can specify a destination domain controller in the command. Repadmin lists INBOUND NEIGHBORS for the current or specified domain controller. INBOUND NEIGHBORS shows the 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 replication succeeded or not, as follows:

Last attempt @ YYYY-MM-DD HH:MM.SS was successful. Last attempt @ [Never] was successful.

If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the destination domain controller. To verify successful replication to a domain controller 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl servername /u:domainname\username /pw:* Term servername domainname Definition Specifies the name of the destination domain controller. Specifies the single-label name of the domain of the destination domain controller. (You do not have to use a fully qualified Domain Name System (DNS) name.) Specifies the name of an administrative account in that domain.

username

3. When you are prompted for a password, type the password for the user account that you provided, and then press ENTER. You can also use Repadmin to generate the details of replication to and from all replication partners in a spreadsheet. The spreadsheet displays data in the following columns: Showrepl_COLUMNS Destination DC Site Destination DC Naming Context

Source DC Site Source DC Transport Type Number of Failures Last Failure Time Last Success Time Last Failure Status The following procedure shows how to create this spreadsheet and set column headers for improved readability. To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl * /csv >showrepl.csv 3. Open Microsoft Excel. 4. On the File menu, click Open, navigate to showrepl.csv, and then click Open. 5. Hide or delete column A as well as the Transport Type column, as follows: 6. Select a column that you want to hide or delete. To hide the column, on the Format menu, click Column, and then click Hide. Or To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row, and then, on the Window menu, click Freeze Panes. 8. Select the entire spreadsheet. On the Data menu, click Filter, and then click AutoFilter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the down arrow, and then click Custom. 11. In the Custom AutoFilter dialog box, under Show rows where, click does

not contain. In the adjacent text box, type del to eliminate from view the results for deleted domain controllers. 12. Repeat step 10 for the Last Failure Time column, but use the value does not equal, and type the value 0. 13. Resolve replication failures. The last successful attempt should agree with the replication schedule for intersite replication, or the attempt should be within the last hour for intrasite replication. If Repadmin reports any of the following conditions, see Troubleshooting Active Directory Replication Problems: The last successful intersite replication was prior to the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful.

See Also
Troubleshooting Active Directory Replication Problems

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. Administrative Credentials To perform this procedure, you must be a member of either the Domain Admins group or the Enterprise Admins group in Active Directory. To seize an operations master role 1. Click Start, click Run, type ntdsutil, and then press ENTER.

2. At the ntdsutil: prompt, type roles and press ENTER. 3. At the fsmo maintenance: prompt, type connections and press ENTER. 4. At the server connections: prompt, type connect to server servername (where servername is the name of the domain controller that will assume the operations master role), and press ENTER. 5. After you receive confirmation of the connection, type quit and press ENTER\. 6. Depending on the role you want to seize, at the fsmo maintenance: prompt, type the appropriate command and press ENTER. Role Domain naming master Schema master Infrastructure master PDC emulator RID master Credentials Enterprise Admins Enterprise Admins Domain Admins Domain Admins Domain Admins Command Seize domain naming master Seize schema master Seize infrastructure master Seize pdc 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. 7. Type quit and press ENTER. Type quit again and press ENTER to exit Ntdsutil.exe.

View the current operations master role holders


Once an operations master role has been transferred, it should be verified that the transfer has occurred successfully throughout the domain. The change must be replicated to all relevant domain members in order to truly take effect. 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. Administrative Credentials To perform this procedure, you must be logged on as a User or an Administrator. To view the current operations master role holder 1. Click Start, click Run, type ntdsutil, and then press ENTER. 2. At the ntdsutil: prompt, type roles and press ENTER. 3. At the fsmo maintenance: prompt, type connections and press ENTER. 4. 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). 5. After receiving confirmation of the connection, type quit and press ENTER to exit this menu. 6. At the fsmo maintenance: prompt, type select operation target and press ENTER. 7. 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 currently assigned to host each role. 8. 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.

Reducing the workload on the PDC emulator master


In addition to processing normal domain controller load from clients, the PDC emulator must also process password changes. In order to mitigate some of the load that is caused by normal domain controller traffic, the PDC can be protected, so the load is distributed to other domain controllers that are capable of processing the requests. You can configure DNS so that a domain controller is queried less frequently than others. 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. 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 or its priority in the DNS environment.

Adjusting the Weight for DNS SRV Records in the Registry


Adjusting the weight of a domain controller to a value less than that of other domain controllers reduces the number of clients that DNS refers to that domain controller. The value is stored in the LdapSrvWeight registry entry. The default value is 100, but it can range from 0 through 65535. 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.

Adjusting the Priority for DNS SRV Records in the Registry


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 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, but 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. Task Requirements The following tool is required to perform the procedures for this task: Regedit.exe

To complete this task, perform the following procedures: 1. Change the weight for DNS SRV records in the registry 2. Change the priority for DNS SRV records in the registry

Change the weight for DNS SRV records in the registry


Use this procedure to reduce the workload on the PDC emulator master by changing the weight for DNS SRV records 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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To change the weight for DNS SRV records in the registry 1. Click Start, click Run, type regedit and then press ENTER. 2. In the Registry Editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. Click Edit, click New, and then click DWORD value. 4. For the new value name, type LdapSrvWeight, and press ENTER. 5. Double-click the value name that you just typed to open the Edit DWORD Value dialog box. 6. Enter a value from 0 through 65535. The default value is 100. 7. Choose Decimal as the Base option, and then click OK. 8. Click File, and then click Exit to close the Registry Editor.

Change the priority for DNS SRV records in the registry


Use this procedure to reduce the workload on the PDC emulator master by changing the priority for DNS SRV records 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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To change the priority for DNS SRV records in the registry 1. Click Start, click Run, type regedit and then press ENTER. 2. In the Registry Editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. Click Edit, click New, and then click DWORD value. 4. For the new value name, type LdapSrvPriority, and press ENTER. 5. Double-click the value name that you just typed to open the Edit DWORD Value dialog box. 6. Enter a value from 0 through 65535. The default value is 0. 7. Choose Decimal as the Base option, and then click OK. 8. Click File, and then click Exit to close the Registry Editor.

Administering Active Directory Backup and Restore


This Administering Active Directory Backup and Restore guide provides administering information for Active Directory backup and restore in the Microsoft Windows Server 2003 operating system. In this guide Introduction to Administering Active Directory Backup and Restore Managing Active Directory Backup and Restore

Acknowledgements Produced by: Microsoft Windows Server User Assistance team Writer: Mary Hillman Editor: Jim Becker

Introduction to Administering Active Directory Backup and Restore


Active Directory backup must be incorporated into your operations schedule for a set of domain controllers that you identify and on which you perform routine backup operations. Active Directory restore is not performed routinely as an operations task; it is performed only when indicated by a failure or other condition from which a domain controller can recover only by restoring the directory to a previous state.

System State Components


Active Directory is backed up as part of system state, a collection of system components that depend on each other. All system state components must be backed up and restored together. The system state components on a domain controller include the following: System startup (boot) files. These files are required for Windows Server 2003 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. System volume (SYSVOL). SYSVOL provides a default location for files that must be shared for common access throughout a domain. The SYSVOL folder on a domain controller contains the following: Net Logon shared folders. These folders usually host user logon scripts and policy settings for network clients that are running preWindows 2000 operating systems. User logon scripts for Active Directoryenabled clients System policies Group Policy settings File system junctions

File Replication service (FRS) staging directories and files that are required to be available and synchronized between domain controllers Active Directory, including the following: The Active Directory database (Ntds.dit) The checkpoint file (Edb.chk) The transaction logs, each 10 megabytes (MB) in size (Edb*.log) Reserved transaction logs (Res1.log and Res2.log)

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.

Purpose of Performing Regular Backups


You need a current, verified, and reliable backup to: Restore Active Directory data that becomes lost. By using an authoritative restore process, you can restore individual objects or sets of objects (containers or directory partitions) from their deleted state. Recover a domain controller that cannot start up or operate normally because of software failure or hardware failure.

Install Active Directory from backup media (using the dcpromo /adv command). You can use this installation option of Dcpromo to install Active Directory on a server running Windows Server 2003 to make that server an additional domain controller. Use this method to quickly add a domain controller to a domain that has a large database or that is located in sites that are separated by slow network links. Perform a forest recovery if forest-wide failure occurs.

Restore Requirements and Recommendations


The tombstone lifetime value in an Active Directory forest defines the default number of days that a domain controller preserves knowledge of deleted objects. This value also defines the useful life of a system state backup that is used for disaster recovery or installation from backup media. Active Directory protects itself from restoring data that is older than the tombstone lifetime by disallowing the restore. Important You should not modify system clocks in an attempt to improperly extend the useful life of a system state backup. System state restore should be undertaken as a last resort, not as primary method of recovering from an error or failure condition.

Backup Guidelines
The following guidelines for backup include the performance of appropriate backups to ensure redundancy of Active Directory data: Perform normal backup. Normal backup is the only type of backup that is available and supported for Active Directory. The Backup tool in Windows Server 2003 supports multiple types of backup: normal, copy, incremental, differential, and daily. You must use normal backup because Active Directory is backed up as part of system state. Perform daily backups of each unique partition on at least two unique domain controllers, with special emphasis on single-domain controller forests, single-domain controller domains, and empty root domains. Where partitions exist in only one site, you can ship backup files offsite to a secure location so that no backup file of a unique directory partition exists in only one physical site at any point in time. This provides an extra level of redundancy. Make sure your backups are stored in a secure location at all times.

Back up Domain Name System (DNS) zones. You must be aware of the location of DNS zones and back up DNS servers accordingly. If you use Active Directoryintegrated DNS, DNS zone data is captured as part of system state on domain controllers that are also DNS servers. If you do not use Active Directory-integrated DNS, you must back up the zone file directories on a representative set of DNS servers for each DNS zone to ensure fault tolerance for the zone. Note The DNS server stores settings in the registry, so system state backup is required for DNS regardless of whether the zone data is Active Directory-integrated or stored in the file system. If you have application partitions in your forest, make sure that you take a backup of the domain controllers that hold those application partitions. Create additional backups in every geographic location where: Mission-critical work is performed. A wide area network (WAN) outage would disrupt business.

The elapsed time that it takes to perform either of the following tasks would be cost-prohibitive because of slow link speeds, the size of the directory database, or both: To create a domain controller in its intended domain over the network. Or To copy or transport a system state backup from a site where a backup exists to a site that has no backup, for the purpose of performing an installation from backup media. Note A backup can be used to restore only the domain controller on which the backup was generated or to create a new additional domain controller in the same domain by installing from backup media. A backup cannot be used to restore a different domain controller or to restore a domain controller onto different hardware. Likewise, a backup that is made on a domain controller running Windows 2000 Server cannot be used to restore a domain controller running Windows Server 2003.

Backup Frequency
Backup frequency depends on criteria that vary for individual environments. In most Active Directory environments, users, computers, and administrators make daily changes to directory objects. For example, computer accounts, including domain controller accounts, change their passwords every 30 days by default. Therefore, every day a percentage of computer passwords changes for domain controllers. Rolling the computer password of a domain controller back to a former state affects authentication and replication. A percentage of user passwords might also expire on a daily basis, and if they are lost as a result of domain controller failure, they must be reset manually. Generally, no record of these changes exists except in Active Directory. Therefore, the more frequently you back up domain controllers, the fewer problems you will encounter if you need to restore. The more Active Directory objects and domain controllers you have, the more frequent your backups should be. For example, in a large organization, to recover from the inadvertent deletion of a large organizational unit (OU) by restoring the domain from a backup that is days or weeks old, you might have to re-create hundreds of accounts that were created in that OU since the backup was taken. To avoid re-creating accounts and potentially performing large numbers of manual password resets, ensure that recent system state backups are always available to recover recent Create, Modify, and Delete operations.

Frequency Criteria
Use the following criteria to assess backup frequency: Small environments with a single domain controller in the forest, or domains that exist in a single physical location (that is, that have a single point of failure): create backups at least daily. Medium (10 to 49 domain controllers) and large environments (50 to 1,000 or more domain controllers): Create backups of each unique directory partition in the forest on two different computers at least daily with an emphasis on backing up application directory partitions, empty root domains, domain partitions in a single geographic site, and sites that have large populations of users or that host mission-critical work. Make backups with increasing frequency until you are confident that if you were to lose the objects that were created or modified since the last backup, the loss would not create an operational disruption. For this reason, major changes to the environment should always be immediately followed by a new system state backup.

Note It is always recommended that you have at least two domain controllers in each domain of your Active Directory forest

Immediate Backup
In addition to regularly scheduled backups, perform an immediate backup when: You have moved the Active Directory database, log files, or both to a different location on a disk. A domain controller is upgraded from Windows 2000 Server to Windows Server 2003 or there are any other operating system upgrades. A Service Pack is installed. A hotfix is installed that makes changes to the Active Directory database.

A current backup is required for installing from backup media for a new domain controller. The tombstone lifetime is changed administratively.

Backup Latency Interval


On domain controllers running Windows Server 2003 with Service Pack 1 (SP1), a new event message, event ID 2089, provides the backup status of each directory partition that a domain controller stores, including application directory partitions. Specifically, event ID 2089 is logged in the Directory Service event log when partitions in the Active Directory forest are not backed up with sufficient frequency, that is, within a backup latency interval. The value for the backup latency interval is stored as a REG_DWORD value in the Backup Latency Threshold (days) entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. By default, the value of Backup Latency Threshold (days) is half the value of the tombstone lifetime of the forest. If halfway through the tombstone lifetime a directory partition has not been backed up, event ID 2089 is logged in the Directory Service event log and continues daily until the directory partition is backed up. This event serves as a warning to administrators and monitoring applications to make sure that domain controllers are backed up before the tombstone lifetime expires. However, it is recommended that you take backups at a much higher frequency than the default value of Backup Latency Threshold (days).

See Also
Installing a Domain Controller in an Existing Domain Using Restored Backup Media

Managing Active Directory Backup and Restore


The following tasks for managing Active Directory backup and restore are described in this objective: Backing Up Active Directory Components Performing a Nonauthoritative Restore of a Domain Controller Performing an Authoritative Restore of Active Directory Objects Performing an Authoritative Restore of an Application Directory Partition Performing an Authoritative Restore of a Group Policy Object

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

Backing Up Active Directory Components


Active Directory is backed up as part of Microsoft Windows system state. For more information about all Microsoft Windows system state components and Active Directory components, see Introduction to Administering Active Directory Backup and Restore.

Naming Backup Files


To ensure the proper use of backup files, the .bkf file should have a file name that includes the following information: The fully qualified computer name that includes the domain name of the domain controller on which the backup was performed Whether the backup domain controller is a global catalog server

Whether the backup domain controller contains MD5 checksum data to source the Sysvol tree The date that the backup was performed

For example, you might use a file name format that is similar to the following: X:\Fully_Qualified_Computer_Name.Build_Number.Service_Pack_Revision. [No]GC. [No]MD5.TSL.YYYYMMDD.bkf where Fully_Qualified_Computer_Name is the host name and the domain name of the domain controller. This must be the domain name of the domain where the system state was backed up. Build Number is the build number of the operating system that was backed up.

Service_Pack_Revision is the service pack build number and the service pack version for the operating system that was backed up. [No]GC indicates whether the backup originated from a global catalog or not.

[No]MD5 indicates whether the system state backup contains MD5 checksum data for the files and folders in the SYSVOL tree. For more information about the need for MD5 data, see Preparing a Server Computer for Shipping and Installation from Backup Media. TSL is the value in days for the tombstoneLifetime attribute when the backup was performed. The tombstoneLifetime attribute for the forest determines both the useful life of a system state backup and how frequently garbage collection occurs. (Garbage collection removes tombstones from the directory permanently when their tombstone lifetime expires.) YYYYMMDD is the year, month, and day that the backup was performed.

For example, suppose that you create a system state backup of a global catalog domain controller on July 1, 2005. The domain controller is in the Contoso.com domain, and its name is DC1. The value of the tombstone lifetime is 60 days, and MD5 data is included in the backup. In this scenario, you might use a file name that is similar to the following: DC1.CONTOSO.COM.3790.SP0.GC.MD5.60.2005.07.01.BKF A system state backup that you make of DC1 on July 1, 2005, remains valid until August 29, 2005. For the next 60 days, you can use the backup to restore an existing domain controller or to install an additional domain controller in the Contoso.com domain. You can save the .bkf file to a local volume or to a network share. The network share can be on a server computer that can be installed later as a domain controller by using the

restored backup. For more information about using restored backup media for installing domain controllers, see Installing a Domain Controller in an Existing Domain Using Restored Backup Media. Task requirements The following tools are required to perform the procedures for this task: Backup or Restore Wizard (Ntbackup) Tape drive or other backup media

To complete this task, perform one of the following procedures, depending on your backup needs: Back up system state Back up system state and the system disk

See Also
Installing a Domain Controller in an Existing Domain Using Restored Backup Media Adding Domain Controllers in Remote Sites

Back up system state


Ntbackup.exe provides simple and advanced options for backing up Active Directory components. When you back up system state, you can choose to include or exclude system-protected boot files. System-protected boot files are not used for installations from restored backup media. When the backup file that you create is to be used for additional domain controller installations, you can clear the advanced option to back up systemprotected files. Clearing this option decreases the size of the .bkf file, as well as the time required to back up, restore, and copy the system state files. Use these procedures to back up the system state only. These procedures do not back up the system disk or any other data on the domain controller except for the system-protected files. Use the first procedure, "To back up system state including system-protected files," for routine system state backup. Use the second procedure, "To back up system state excluding system-protected files," if you want to create a smaller backup that is effective for installing domain controllers from restored backup media.

Note To back up system state, you must log on locally to the domain controller, or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform the following two procedures, you must be a member of the Domain Admins group or a member of the Backup Operators group. To back up system state including system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. This procedure provides steps for backing up in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard. 2. On the Welcome to the Backup or Restore Wizard page, click Next. 3. Select Back up files and settings, and then click Next. 4. Select Let me choose what to back up, and then click Next. 5. In the Items to Back Up window, double-click My Computer. 6. In the expanded list below My Computer, check System State, and then click Next. 7. Select a location to store the backup: If you are backing up to a file, type the path and file name for the backup (.bkf) file (or click Browse to find a folder or file). If you are backing up to a tape unit, choose the tape that you want to use. Note You should not store the backup on the local hard drive. Instead, store it in a location, such as a tape drive, away from the computer that you are backing up. 8. Type a name for this backup according to the recommendations in Backing Up Active Directory Components, and then click Next. 9. On the last page of the wizard, click Advanced. 10. Do not change the default options for Type of Backup. Normal should be

selected, and the check box for Backup migrated remote storage data should remain cleared. Click Next. 11. Select Verify data after backup, and then click Next. 12. In the Backup Options dialog box, select a backup option, and then click Next. 13. If you are replacing the existing backups, select the option to allow only the owner and administrator access to the backup data and to any backups that are appended to this medium, and then click Next. 14. In the When to back up box, select the appropriate option for your needs, and then click Next. 15. If you are satisfied with all of the options that are selected, click Finish to perform the backup operation according to your selected schedule. Note The system state can also be backed up by using Ntbackup from a command line with appropriate parameters. For more information, at a command prompt type ntbackup /?. The following procedure produces a smaller .bkf file that does not include system boot files. By using this procedure, you can reduce the time that is required to perform the backup and subsequent restore, as well as the amount of disk space that is required. This method is recommended when the restored backup is to be used for installing additional domain controllers. To back up system state excluding system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. 2. On the Welcome to the Backup or Restore Wizard page, click Advanced Mode, and then click the Backup tab. 3. In the console tree, select the System State check box. 4. In Backup media or file name, type a name for this backup according to the recommendations in Backing Up Active Directory Components. 5. Click Start Backup, and then click Advanced. 6. Clear the Automatically back up System Protected Files with the System State check box, and then click OK. 7. Click Start Backup.

See Also
Enable Remote Desktop Create a Remote Desktop Connection

Back up system state and the system disk


Use this procedure to back up both the system state and the system disk. Note To back up system state and the system disk, you must log on locally to the domain controller or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or a member of the Backup Operators group. To back up system state and the system disk 1. To start the Windows Server 2003 backup utility, click Start, point to Programs, Accessories, System Tools, and then click Backup. This procedure requires Backup Utility Advanced Mode. If the Welcome to the Backup or Restore Wizard appears when you click Backup in step 1, clear Always start in wizard mode, close the wizard, and then repeat step 1. 2. On the Welcome to the Backup Utility Advanced Mode page, click the Backup Wizard (Advanced) button. 3. On the Welcome to the Backup Wizard page, click Next. 4. On the What to Back Up page, click Back up selected files, drives, or network data, and then click Next. 5. In Items to Back Up, select the System State check box. Then, locate the drive letter containing the system files, click the check box for it, and then click Next. 6. In Backup Type, Destination, and Name, select the backup media type by choosing one of the following options:

In the Select the backup type box, click File if you want to back up to a file. If you do not have a tape backup unit installed, File is selected automatically. Or Select a tape device if you want to back up to tape.

7. In the Choose a place to save your backup box, select one of the following options, and then click Next: If you are backing up to a file, if you want to change the current backup file location, click Browse to find a folder or file. If the destination folder or file does not exist, the system creates it. Or If you are backing up to a tape unit, select the tape that you want to use.

8. On the Completing the Backup Wizard page, click Advanced. Do not change the default options for Type of Backup. Normal should be selected, and the check box should remain cleared for Backup migrated remote storage data. Click Next. 9. Click Verify data after backup, and then click Next. 10. In the Backup Options dialog box, select a backup option, and then click Next. 11. If you are replacing the existing backups, select the option to allow only the owner and administrator access to the backup data and to any backups that are appended to this medium, and then click Next. 12. In the When to back up box, select the appropriate option for your needs, and then click Next. 13. If you are satisfied with all of the options that are selected, click Finish to perform the backup operation according to your selected schedule.

See Also
Enable Remote Desktop Create a Remote Desktop Connection

Performing a Nonauthoritative Restore of a Domain Controller


A nonauthoritative restore is the default method for restoring Active Directory. To perform a nonauthoritative restore, you must be able to start the domain controller in Directory Services Restore Mode. After you restore the domain controller from backup media, replication partners use the standard replication protocols to update Active Directory and associated information on the restored domain controller. A nonauthoritative restore returns the domain controller to its state at the time of backup and then allows normal replication to overwrite that state with any changes that 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. A nonauthoritative restore allows the entire directory to be restored on a domain controller, without reintroducing or changing objects that have been modified since the backup. The most common use of a nonauthoritative restore is to bring an entire domain controller back, often after catastrophic or debilitating hardware failures. It is uncommon for data corruption to drive a nonauthoritative restore, unless the corruption is local and the database cannot be successfully loaded. If you intend to restore a deleted object (or objects), you should refer to the procedures for an authoritative restore. You can perform a nonauthoritative restore on a Windows Server 2003 system that is a stand-alone server, member server, or domain controller. You must start a server in Directory Services Restore Mode to perform a nonauthoritative restore. Note By performing a nonauthoritative restore on Active Directory, you automatically perform a nonauthoritative restore of the system volume (SYSVOL); no additional steps are required. Task requirements The following tool is required to perform the procedures for this task: NTBackup.exe

To complete this task, perform the following procedures:

1. Restart the domain controller in Directory Services Restore Mode by using one of the following methods: Restart the domain controller in Directory Services Restore Mode locally Restart the domain controller in Directory Services Restore Mode Remotely

Note In cases in which you have to reinstall the operating system, before you restore the directory, you do not have to perform a nonauthoritative restore in Directory Services Restore Mode. After you reinstall the operating system, you can perform a restore after the computer boots normally. 2. Restore from backup media 3. Verify Active Directory restore

See Also
Performing an Authoritative Restore of Active Directory Objects Enable Remote Desktop Create a Remote Desktop Connection

Restart the domain controller in Directory Services Restore Mode locally


If you have physical access to a domain controller, you can restart the domain controller in Directory Services Restore Mode locally. Restarting in Directory Services Restore Mode takes the domain controller offline. In this mode, the server is not functioning as a domain controller. When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode.

To restart the domain controller in Directory Services Restore Mode locally 1. Restart the domain controller. 2. When the screen for selecting an operating system appears, press F8. 3. On the Windows Advanced Options menu, select Directory Services Restore Mode. 4. When you are prompted, log on as the local administrator.

See Also
Restart the domain controller in Directory Services Restore Mode Remotely

Restart the domain controller in Directory Services Restore Mode Remotely


If Remote Desktop is enabled on a domain controller, you can use Remote Desktop Connection to connect to the domain controller remotely. Remote Desktop Connection (formerly known as the Terminal Services client) is installed by default on all Windows Server 2003 family operating systems. If you use Remote Desktop Connection to connect to a domain controller remotely and you want to restart the domain controller in Directory Services Restore Mode, you must first modify the Boot.ini file on the remote server so that you do not lose the connection when the domain controller restarts. When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restart the domain controller in Directory Services Restore Mode remotely 1. Use Remote Desktop Connection to connect to the domain controller that you want to restart in Directory Services Restore Mode.

2. Right-click My Computer, click Properties, and then click the Advanced tab. 3. Click Settings for startup and recovery. 4. Click the Edit button to edit the startup options file. 5. 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 and Windows Server 2003. 6. Save the modified Boot.ini file, and then close Notepad. 7. On the Start menu, click Shut Down, and then click Restart. During the restart process, the Terminal Services client reports that the session is disconnected. Caution Be sure to click Restart and not Shut Down at this step. If you click Shut Down, you cannot restart the domain controller remotely. 8. Wait until the restart process completes on the remote domain controller, and then reconnect the client session. 9. When the client session is reconnected, log on as the local administrator. 10. Right-click My Computer, click Properties, and then click the Advanced tab. 11. Click Settings for startup and recovery. 12. Click the Edit button to edit the startup options file. 13. Delete the /SAFEBOOT:DSREPAIR switch from the default entry in the Boot.ini file, save the file, and then close Notepad. Important If you restart the domain controller before you modify the Boot.ini file, the domain controller remains offline. The Boot.ini file is now returned to its original state, which starts the domain controller normally.

See Also
Enable Remote Desktop Create a Remote Desktop Connection Restart the domain controller in Directory Services Restore Mode locally

Restore from backup media


To restore the server, use a good backup containing the system state or the system state and system disk. Note To restore from backup, you must log on locally to the domain controller or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restore from backup media 1. Start the computer in Directory Services Restore Mode. 2. To start the Windows Server 2003 backup utility, click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup. This procedure provides steps for restoring from backup in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard. 3. On the Welcome to the Backup or Restore Wizard page, click Next. 4. Click Restore files and settings, and then click Next. 5. Select System State, and then click Next. 6. On the Completing the Backup or Restore Wizard page, click Advanced. 7. In Restore files to, click Original Location, and then click Next.

8. Click Leave existing files (Recommended), and then click Next. 9. In Advanced Restore Options, select the following check boxes, and then click Next: Restore security settings

Restore junction points, but not the folders and file data they reference Preserve existing volume mount points

10. For a primary restore of SYSVOL, also select the following check box: When restoring replicated data sets, mark the restored data as the primary data for all replicas. A primary restore is required only if the domain controller that you are restoring is the only domain controller in the domain. A primary restore is required on the first domain controller that is being restored in a domain if you are restoring the entire domain or forest. 11. Click Finish. 12. When the restore process is complete, click Close, and then do one of the following: If you do not want to authoritatively restore any objects, click Yes to restart the computer. The system will restart and replicate any new information that is received since the last backup with its replication partners. If you want to authoritatively restore any objects or if you want to create an LDAP Data Interchange Format (LDIF) file to restore back-links on this domain controller, click No to remain in Directory Services Restore Mode. For information about how to proceed with authoritative restore, see Performing an Authoritative Restore of Active Directory Objects.

See Also
Restart the domain controller in Directory Services Restore Mode locally Enable Remote Desktop Create a Remote Desktop Connection Restart the domain controller in Directory Services Restore Mode Remotely Restore system state to an alternate location Performing an Authoritative Restore of Active Directory Objects

Verify Active Directory restore


After the restore is completed, use this procedure to restart the server and perform basic verification. Administrative credentials To verify Active Directory restore, you must be a member of the Domain Admins group. To verify Active Directory restore 1. After the restore operation completes, restart the computer in Start Windows Normally mode. Active Directory and Certificate Services automatically detect that they have been recovered from a backup. They perform an integrity check and reindex the database. 2. After you are able to log on to the system, browse Active Directory. Verify that all of the User objects and Group objects that were present in the directory prior to backup are restored. Similarly, verify that files that were members of a File Replication service (FRS) replica set and certificates that were issued by the Certificate Services are present.

Performing an Authoritative Restore of Active Directory Objects


On the domain controller that is being restored, an authoritative restore process returns a designated object or container of objects to its state at the time of the backup. For example, you might need to perform an authoritative restore if an administrator inadvertently deletes an organizational unit (OU) containing a large number of users. If you restore the server from backup, the normal, nonauthoritative restore process does not restore the inadvertently deleted OU because the restored domain controller is updated following the restore process to the current status of its replication partners, which have deleted the OU. Recovering the deleted OU requires authoritative restore. You can use authoritative restore to mark the OU as authoritative and let the replication process restore it to all the other domain controllers in the domain. When an object is marked for authoritative restore, its version number is changed so that it is higher than the existing version number of the (deleted) object in the Active Directory

replication system. This change ensures that any data that you restore authoritatively is replicated from the restored domain controller to other domain controllers in the forest. An authoritative restore should not be used to restore an entire domain controller, nor should it be used as part of a change-control infrastructure. Proper delegation of administration and change enforcement will optimize data consistency, integrity, and security. It is important to ensure successful recovery of the information that is being restored. Group membership is particularly sensitive and can be affected greatly by the procedures that are followed during an authoritative restore.

Group Membership Restoration Following Authoritative Restore


When a user object is inadvertently deleted, you can restore it by marking the user object as authoritative during an authoritative restore procedure. However, depending on the functional level of the forest at the time that any groups to which the user belongs were created (or the forest functional level at the time that the user was added to the group, if they are different), the user's group memberships might not be restored in the process. Multiply this condition by hundreds or thousands of users when an OU is deleted. In this case, additional steps are required to restore the group memberships of user accounts that are restored.

LVR and Restoration of Group Memberships


Restoration of group memberships for user objects that are deleted and restored authoritatively differs, depending on whether the group was created (or its membership was updated) before or after the implementation of Windows Server 2003 functionality called linked-value replication (LVR). LVR is a feature that is available when the forest has a functional level of Windows Server 2003 interim or Windows Server 2003. In groups that are created before LVR is in effect, the member attribute is replicated as a single value. Therefore, any change to the group's membership results in replication of the entire member attribute. In groups that are created after LVR is in effect, or in groups that are created before LVR but that are updated after LVR is in effect, updates to the member attribute are replicated separately. In this case, group memberships are restored when you use Ntdsutil to authoritatively restore a user, group, or computer object. The memberOf attribute (or any back-link attribute) is generated only because of its link to the member attribute (or any corresponding forward-link attribute). For this reason,

restoring the membership on a user object necessarily involves updating the member attribute on the group object to include the distinguished name of the restored user. Note Only the forward-link attribute value can be updated and replicated. The back-link attribute value is generated only when it is accessed. It is not stored on the object, and it is not replicated. When you use the Ntdsutil command-line tool to authoritatively restore a subtree or single object, the ability of Ntdsutil to restore the group memberships of an object that is authoritatively restored depends on whether the group was created before or after LVR was implemented. For example, if a user object is restored and the user belongs to group G1 that was created before LVR was implemented and the user belongs to group G2 that was created after LVR was implemented (the functional level of the forest was raised to Windows Server 2003 interim or Windows Server 2003), the member attribute of G2 is updated during authoritative restore (and, therefore, the memberOf attribute of the restored user is updated), but the member attribute of G1 is not updated. However, improvements in the version of Ntdsutil that is included with Windows Server 2003 Service Pack 1 (SP1) provide the ability to also restore the memberships of groups that were created before LVR was implemented.

Authoritative Restore Improvements in Windows Server 2003 SP1


On a domain controller running Windows Server 2003 with SP1, Ntdsutil now creates a text file that identifies the authoritatively restored objects and uses this file to create an LDAP Data Interchange Format (LDIF) file. The LDIF file can be used to regenerate all back-links on the restored objects in a forest where LVR is not in effect. If you need to restore a large number of users (for example, if you delete an OU) in domain X and your forest also contains domain Y and domain Z, authoritative restore requires the restoration of domain X and then the use of Ntdsutil to generate and run the LDIF file against a domain controller in each additional domain. In all cases, you begin the authoritative restore process by performing a nonauthoritative restore from backup media. Then, you perform the additional steps to complete the authoritative restore and restore group memberships, if necessary. The steps that you perform are different if you are restoring the objects on a domain controller running Windows Server 2003 with SP1.

Procedures for Domain Controllers Running Windows Server 2003 with SP1
These procedures include the use of an LDIF file to restore group memberships following authoritative restore of the objects. If you are restoring objects that can belong to groups in more than one domain, additional steps are required. Task requirements The following tools are required to perform the procedures for this task: Ntbackup.exe Ntdsutil.exe Repadmin.exe

To complete this task, perform the following procedures in order: 1. Restore from backup media Restore system state to return the domain controller to its state at the time of the backup. To ensure that replication does not occur, click No at the end of the procedure so that the domain controller does not restart. 2. Mark the object or objects authoritative Mark the object or objects that you want to restore so that replication does not overwrite them when you restart the domain controller. 3. Restart the domain controller normally. 4. Synchronize replication with all partners For the newly restored object to become available and be instantiated in its restored form on all domain controllers, successful replication must occur between the domain controller that originates the restored changes and its partners. Make sure that all domain controllers in the domain and all global catalog servers in the forest have received the restored objects. 5. Use the following procedure to run the LDIF file that was created in step 2 on this domain controller to add the missing group memberships in the domain that you have just restored: Run an LDIF file to recover back-links 6. If you are restoring user or group objects in a forest that has more than one domain, perform the following steps on a domain controller in another domain: a. Restart the domain controller in Directory Services Restore Mode locally

b. Restore from backup media c. While still in Directory Services Restore Mode, use Ntdsutil to Create an LDIF file for recovering back-links for authoritatively restored objects d. Restart the domain controller normally (not in Directory Services Restore Mode). e. Run an LDIF file to recover back-links in this domain on a different domain controller than the one on which you created the LDIF file 7. Repeat step 6 for each additional domain.

Procedures for Domain Controllers Running Windows Server 2003 with No Service Pack Installed
To complete this task, perform the following procedures in order: Note If the objects that were deleted do not include group objects, you do not have to perform steps 3 through 10. In addition, if the groups that were deleted do not have members among the list of deleted objects, you do not have to perform steps 3 through10. 1. Restore from backup media Restore system state to return the domain controller to its state at the time of the backup. To ensure that replication does not occur, click No at the end of the procedure so that the domain controller does not restart. 2. Mark the object or objects authoritative Mark the object or objects that you want to restore so that replication does not overwrite them when you restart the domain controller. 3. Restart the computer normally, but in isolation. This step allows you to control replication so that inbound replication does not update any restored object before forcing outbound replication. You cannot turn off inbound replication in Directory Services Restore Mode. The most common way to start a computer in isolation is to remove the network connection from the domain controller by physically removing the network cable. Alternative methods may be possible, depending on your network hardware and enterprise practices.

It is important to prevent the domain controller from communicating with any other domain controller in the domain or forest. You should also isolate the domain controller from any clients that might change an object in the directory. 4. Turn off inbound replication This step is required only if the domain or forest functional level is Windows 2000 native or earlier. By turning off inbound replication, you ensure that no changes replicate in to the domain controller and alter group membership. 5. Reconnect the computer to the network. After you turn off inbound replication, it is safe to reconnect the domain controller to the network. If you isolated your computer by removing the network cable or by disconnecting the network connection from the domain controller, reconnect it to bring the domain controller back onto the network. If you followed other procedures based on your enterprise network equipment, follow the equipment's recommendations for reconnecting the domain controller to the network. 6. Synchronize replication with all partners For the newly restored object to become available and be instantiated in its restored form on all domain controllers, successful replication must occur between the domain controller that originates the restored changes and its partners. Make sure that all domain controllers in the domain and all global catalog servers in the forest have received the restored objects. 7. Restart the domain controller in Directory Services Restore Mode locally 8. Mark the object or objects authoritative One of the challenges of restoring objects, and their group memberships, is the fact that the membership and object may replicate in different orders. If the membership replicates before a user is restored, the receiving domain controller will not update the membership because the user does not exist. To overcome the effects of this behavior, it is necessary to mark the objects that have been restored as authoritative a second time and once again have the information replicated out. 9. Restart the computer normally (not in Directory Services Restore Mode). After the authoritative restore of the object or objects has completed a second time, you can restart the domain controller in normal mode. 10. Turn on inbound replication

Restore from backup media


To restore the server, use a good backup containing the system state or the system state and system disk. Note To restore from backup, you must log on locally to the domain controller or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restore from backup media 1. Start the computer in Directory Services Restore Mode. 2. To start the Windows Server 2003 backup utility, click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup. This procedure provides steps for restoring from backup in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard. 3. On the Welcome to the Backup or Restore Wizard page, click Next. 4. Click Restore files and settings, and then click Next. 5. Select System State, and then click Next. 6. On the Completing the Backup or Restore Wizard page, click Advanced. 7. In Restore files to, click Original Location, and then click Next. 8. Click Leave existing files (Recommended), and then click Next. 9. In Advanced Restore Options, select the following check boxes, and then click Next: Restore security settings

Restore junction points, but not the folders and file data they reference

Preserve existing volume mount points

10. For a primary restore of SYSVOL, also select the following check box: When restoring replicated data sets, mark the restored data as the primary data for all replicas. A primary restore is required only if the domain controller that you are restoring is the only domain controller in the domain. A primary restore is required on the first domain controller that is being restored in a domain if you are restoring the entire domain or forest. 11. Click Finish. 12. When the restore process is complete, click Close, and then do one of the following: If you do not want to authoritatively restore any objects, click Yes to restart the computer. The system will restart and replicate any new information that is received since the last backup with its replication partners. If you want to authoritatively restore any objects or if you want to create an LDAP Data Interchange Format (LDIF) file to restore back-links on this domain controller, click No to remain in Directory Services Restore Mode. For information about how to proceed with authoritative restore, see Performing an Authoritative Restore of Active Directory Objects.

See Also
Restart the domain controller in Directory Services Restore Mode locally Enable Remote Desktop Create a Remote Desktop Connection Restart the domain controller in Directory Services Restore Mode Remotely Restore system state to an alternate location Performing an Authoritative Restore of Active Directory Objects

Mark the object or objects authoritative


In this procedure, you select which objects are to be marked authoritative to have them replicate to other domain controllers. You must have completed a nonauthoritative restore procedure, following which the domain controller has not been restarted and remains in

Directory Services Restore Mode. To complete this procedure, you must know the full distinguished name of the object or objects that you want to restore. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To mark a subtree or individual object authoritative 1. In Directory Services Restore Mode, click Start, click Run, type ntdsutil, and then press ENTER. 2. At the ntdsutil: prompt, type authoritative restore, and then press ENTER. 3. To restore a subtree or individual object, type one of the following commands, as appropriate, and then press ENTER: To restore a subtree (for example, an organizational unit and all child objects): restore subtree DistinguishedName To restore a single object: restore object DistinguishedName
DistinguishedName

The distinguished name of the subtree or object that is to be marked authoritative 4. Click Yes in the message box to confirm the command. For example, if you want to restore a deleted organizational unit named Marketing NorthAm in the corp.contoso.com domain, type: restore subtree OU=Marketing NorthAm,DC=corp,DC=contoso,DC=com (Always enclose the distinguished name in quotes when there is a space or other special characters within the distinguished name.) Ntdsutil attempts to mark the object as authoritative. The output message indicates the status of the operation. The most common cause of failure is an incorrectly specified distinguished name or a backup for which the distinguished name does not exist (which occurs if you try to restore a deleted user that was created after the backup). If you are running this command on a domain controller running Windows Server 2003 with Service Pack 1 (SP1), Ntdsutil provides output that indicates whether a restored object has back-links that must be restored. If objects

that have back-links are found, Ntdsutil generates a set of files that you can use to restore the back-links in this domain and in other domains, if necessary. The following sample output on a domain controller running Windows Server 2003 with SP1 shows that Ntdsutil created a text file (.txt) and an LDAP Data Interchange Format (LDIF) file (.ldf) when the marked object was found to have back-links:

Successfully updated 3 records. The following text file with a list of authoritatively restored objects has been created in the current working directory: ar_20050209-091249_objects.txt One or more specified objects have back-links in this domain. The following LDIF files with link restore operations have been created in the current working directory: ar_20050209-091249_links_Test1.com.ldf Authoritative Restore completed successfully.

5. Make a note of the location of the .txt and .ldf files, if any. You will use the .ldf file to restore back-links in this domain. You will use the .txt file to generate an LDIF file to restore back-links in a different domain, if necessary. If you have other domains in which you want to restore back-links for this restored object, make a copy of this .txt file to use on a domain controller in another domain. 6. At the authoritative restore: and ntdsutil: prompts, type quit, and then press ENTER. 7. Restart the domain controller in normal operating mode, as follows: a. For a domain controller running Windows Server 2003 with no service pack installed: Disconnect the domain controller from the network, and then restart normally. Follow the instructions in "Procedures for Domain Controllers Running Windows Server 2003 with No Service Pack Installed" as described in Performing an Authoritative Restore of Active Directory Objects. b. For a domain controller running Windows Server 2003 with SP1: Restart the domain controller normally, and then follow the instructions in "Procedures for Domain Controllers Running Windows Server 2003 with SP1" as described in Performing an Authoritative Restore of Active Directory Objects.

Synchronize replication with all partners


You can use this procedure to synchronize replication with all replication partners of a domain controller. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the selected domain controller or the Enterprise Admins group in the forest, or you must have been delegated the appropriate authority. If you want to synchronize the configuration and schema directory partitions on a domain controller in a child domain, you must have Domain Admins credentials in the forest root domain or Enterprise Admins credentials in the forest. To synchronize replication with all partners 1. At a command prompt, type the following command, and then press ENTER: repadmin /syncall DCName /e /d /A /P /q Term DCName Definition The Domain Name System (DNS) name of the domain controller on which you want synchronize replication with all partners Enterprise; includes partners in all sites. Identifies servers by distinguished name in messages. All; synchronizes all directory partitions that are held on the home server. Pushes changes outward from the home server. Runs in quiet mode; suppresses callback messages.

/e /d /A /P /q

2. Check for replication errors in the output of the command in the previous step. If there are no errors, replication is successful. For replication to complete, any errors must be corrected.

See Also
Verify successful replication to a domain controller

Run an LDIF file to recover back-links


Ntdsutil in Windows Server 2003 Service Pack 1 (SP1) provides new functionality for performing authoritative restore of objects that have back-links. The output of the authoritative restore procedure includes the name of an LDAP Data Interchange Format (LDIF) (.ldf) file that contains the forward-links that are required so that the group memberships (back-links) of any restored user, group, or computer objects can be recovered. For each object or subtree that you restore, you must run the LDIF file on a domain controller in each domain that might have group objects that are required to recover back-links on the restored objects. Note This procedure is critical for recovering group memberships for deleted users, groups, or computers, but it applies to any restored objects that have back-link attributes. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the domain controller on which you run the command. To run an LDIF file to recover back-links following authoritative restore 1. Open a command prompt and change directories, if necessary, to the directory of the .ldf file and its respective log files. 2. At the command prompt, type the following command, and then press ENTER: ldifde -i -k -f FileName
FileName

The name of the .ldf file that you want to run, for example, ar_20050609174604_links_corp.contoso.com.ldf

See Also
Create an LDIF file for recovering back-links for authoritatively restored objects

Restart the domain controller in Directory Services Restore Mode locally


If you have physical access to a domain controller, you can restart the domain controller in Directory Services Restore Mode locally. Restarting in Directory Services Restore Mode takes the domain controller offline. In this mode, the server is not functioning as a domain controller. When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restart the domain controller in Directory Services Restore Mode locally 1. Restart the domain controller. 2. When the screen for selecting an operating system appears, press F8. 3. On the Windows Advanced Options menu, select Directory Services Restore Mode. 4. When you are prompted, log on as the local administrator.

See Also
Restart the domain controller in Directory Services Restore Mode Remotely

Create an LDIF file for recovering backlinks for authoritatively restored objects
If you have authoritatively restored objects that have back-links in another domain, you can use this procedure to create an LDAP Data Interchange Format (LDIF) file that you can run

against a domain controller in that domain to restore the back-links. Perform this procedure on a domain controller in the domain that has the back-links. Before you perform this procedure, you must: Copy the .txt file that Ntdsutil created during the authoritative restore procedure, which you performed on the first domain controller, to a location on this domain controller or a network share. Restore this domain controller from backup media.

After you restore this domain controller from backup media, perform this procedure while the domain controller is still running in Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To create an LDIF file for restoring back-links for authoritatively restored objects 1. In Directory Services Restore Mode, click Start, click Run, type ntdsutil, and then press ENTER. 2. At the ntdsutil: prompt, type authoritative restore, and then press ENTER. 3. At the authoritative restore: prompt, type the following command, and then press ENTER: create ldif files from TextFilePath where TextFilePath is the location and file name of the .txt file that Ntdsutil created during the initial authoritative restore of the object whose back-links you want to restore, for example, d:\ldif\ar_20050609_091558_objects.txt. Ntdsutil displays a message stating that one or more specified objects have backlinks in this domain and an LDIF file has been created in the current working directory. 4. At the authoritative restore: and ntdsutil: prompts, type quit.

See Also
Restore from backup media Run an LDIF file to recover back-links

Turn off inbound replication


You can use this procedure to turn off inbound replication so that objects on a domain controller cannot be updated by replication from another domain controller. Administrative credentials To complete this procedure, you must be a member of the Domain Admins group in the domain of the domain controller whose replication you are disabling, or you must be a member of the Enterprise Admins group. To turn off inbound replication 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /options ServerName +DISABLE_INBOUND_REPL where ServerName is the network basic input/output system (NetBIOS) name of the domain controller. 3. Verify that the option is set. The following message should appear: New DC Options: DISABLE_INBOUND_REPL

See Also
Turn on inbound replication

Turn on inbound replication


You can use this procedure to turn on inbound replication after it has been turned off manually. Administrative credentials To complete this procedure, you must be a member of the Domain Admins group in the domain of the domain controller whose replication you are enabling, or you must be a member of the Enterprise Admins group. To turn on inbound replication 1. Open a Command Prompt.

2. Type the following command, and then press ENTER: repadmin /options ServerName -DISABLE_INBOUND_REPL where ServerName is the network basic input/output system (NetBIOS) name of the domain controller. 3. Verify that the option is set. The following message should appear: Current DC options: DISABLE_INBOUND_REPL New DC Options: <none> Current DC Options displays the conditions that were in effect at the time that you ran the command. New DC Options shows the effect of the command, which is that the option to disable replication is not set.

See Also
Turn off inbound replication

Performing an Authoritative Restore of an Application Directory Partition


Restoration of an application partition will mark all data that is present in the application partition as authoritative for the replica set. Information that is contained within an application partition will replicate to all domain controllers in the forest that were previously present in the replica set. You should have a current valid backup of the application partition prior to restoring, in the event that particular object changes are lost because of changes since backup. Task Requirements The following tools are required to perform the procedures for this task: Backup.exe Ntdsutil.exe

To complete this task, perform the following procedures: 1. Restore from backup media 2. Mark the application directory partition as authoritative 3. Restart the computer

Once the authoritative restore of the object or objects has been completed a second time, the domain controller can be restarted in normal mode.

Restore from backup media


To restore the server, use a good backup containing the system state or the system state and system disk. Note To restore from backup, you must log on locally to the domain controller or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restore from backup media 1. Start the computer in Directory Services Restore Mode. 2. To start the Windows Server 2003 backup utility, click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup. This procedure provides steps for restoring from backup in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard. 3. On the Welcome to the Backup or Restore Wizard page, click Next. 4. Click Restore files and settings, and then click Next. 5. Select System State, and then click Next. 6. On the Completing the Backup or Restore Wizard page, click Advanced. 7. In Restore files to, click Original Location, and then click Next. 8. Click Leave existing files (Recommended), and then click Next. 9. In Advanced Restore Options, select the following check boxes, and then click Next:

Restore security settings

Restore junction points, but not the folders and file data they reference Preserve existing volume mount points

10. For a primary restore of SYSVOL, also select the following check box: When restoring replicated data sets, mark the restored data as the primary data for all replicas. A primary restore is required only if the domain controller that you are restoring is the only domain controller in the domain. A primary restore is required on the first domain controller that is being restored in a domain if you are restoring the entire domain or forest. 11. Click Finish. 12. When the restore process is complete, click Close, and then do one of the following: If you do not want to authoritatively restore any objects, click Yes to restart the computer. The system will restart and replicate any new information that is received since the last backup with its replication partners. If you want to authoritatively restore any objects or if you want to create an LDAP Data Interchange Format (LDIF) file to restore back-links on this domain controller, click No to remain in Directory Services Restore Mode. For information about how to proceed with authoritative restore, see Performing an Authoritative Restore of Active Directory Objects.

See Also
Restart the domain controller in Directory Services Restore Mode locally Enable Remote Desktop Create a Remote Desktop Connection Restart the domain controller in Directory Services Restore Mode Remotely Restore system state to an alternate location Performing an Authoritative Restore of Active Directory Objects

Mark the application directory partition as authoritative


You can select which application directory partitions are to be marked authoritative so that you can have them replicated to other domain controllers. To perform this procedure, you must have completed a nonauthoritative restore procedure. After that procedure is complete, the domain controller is not restarted, and it remains in Directory Services Restore Mode. Administrative credentials To complete this procedure, you must provide the Administrator password for Directory Services Restore Mode. To mark an application directory partition as authoritative 1. In Directory Services Restore Mode, open a Command Prompt. 2. Type the following command, and then press ENTER: ntdsutil 3. At the ntdsutil: prompt, type authoritative restore, and then press ENTER. For assistance with the Ntdsutil command line-tool, type help at any time. 4. Type List NC CRs, and then press ENTER. Ntdsutil displays a list of the application directory partitions that are available after the restore, along with the associated cross-references. Note the cross-reference distinguished name and application directory partition distinguished name that correspond to the application directory partition that you want to restore. 5. Type restore subtree App Partition DN, where App Partition DN is the distinguished name of the application directory partition that you want to restore. 6. In the confirmation dialog box, click Yes. The output message indicates the status of the operation. There should be no failures. 7. Type restore object Cross Ref DN (where Cross Ref DN is the distinguished name of the application directory partition cross-reference that you want to restore), and then press ENTER. 8. In the confirmation dialog box, click Yes. The output message indicates the status of the operation. There should be no

failures. 9. Quit the Ntdsutil tool.

Performing an Authoritative Restore of a Group Policy Object


Restoring a Group Policy Object (GPO) restores the GPO to a previous state. A restore operation can be used in both of the following cases: the GPO was backed up but has since been deleted, or the GPO is live and you want to roll back to a known previous state. A restore operation retains the original GPO GUID even if the restore is recreating a deleted GPO. This is a key difference between the restore operation and the import or copy operations discussed in later sections of this guide. A restore operation replaces the following components of a GPO: GPO settings ACLs on the GPO WMI filter links (but not the filters themselves)

The restore operation does not restore links to a SOM (Scope of Management). Any existing links will continue to be usedfor example, when restoring an existing GPO to a previous state. However, if the user has deleted a GPO and all links to the GPO, the user must recreate these links after restoring the GPO. To facilitate recreating these links, you can view the report in the backup to identify all links in the domain of the GPO. For more information, see Administering Group Policy with the GPMC on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=17528). Task Requirements The following tool is required to perform the procedures for this task: Group Policy Management Console

To complete this task, perform the following procedure: Restore a Group Policy Object

Restore a Group Policy Object


Use this procedure to perform an authoritative restore of a Group Policy object. Administrative credentials To perform this procedure, you must have edit, delete , and modify permissions on the specific Group Policy object. To restore a Group Policy object 1. Open Group Policy Management Console (GPMC). 2. In the console tree, double-click Domains to expand the list of domains. 3. Double-click the desired domain to expand the contents of that domain. 4. Right-click Group Policy Objects, and select Manage Backups. 5. Right-click the object to be restored, and select Restore from Backup. 6. Select the backup location, click the policy backup to be restored, and then click Restore. 7. Click OK to restore the selected GPO backup.

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 it through reinstallation of the operating system and subsequent restore of Active Directory from backup. After you reinstall Windows Server 2003, perform a nonauthoritative restore of the system state and the system disk. You do not need to join the computer to the domain before performing the restore procedure. During the restore, the computer account is reestablished automatically.

Note The restore procedure must be performed by using the same backup tool with which the backup was made. Procedures in this task describe using Ntbackup to restore Active Directory, but you must use the tool that you used to create the backup file if it is not Ntbackup. 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 the failure was caused by a hardware failure, you have resolved the hardware problem (for example, by replacing the disk). You have a previous backup for the failed domain controller that is not older than the tombstone lifetime for the forest. The domain controller is running other server services such as Exchange, or it contains other data that you must restore from a backup. 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. In the case of a complete disk failure, use this information to recreate the disk configuration. Windows Server 2003 must be reinstalled to the same drive letter and with at least the same amount of physical drive space. Before you restore the system state, you must recreate all disk configurations. Failure to recreate all disk configurations can cause the restore process to fail and can prevent you from starting the domain controller after the restore. Computer name. You need the computer name to restore a domain controller of the same name and avoid changing client configuration settings. Password for the local computer Administrator account. You must know the local Administrator password that was used when the backup was created. The local Administrator password is also required to restore the system state on a domain controller. Task requirements The following tool is required to perform the procedures for this task: Ntbackup.exe

To complete this task, perform the following procedures: 1. Install Windows Server 2003.

Note This guide does not provide information for the installation of Windows Server 2003. 2. Restore from backup media a. Begin with step 2 of this procedure. You cannot start the server in Directory Services Restore Mode because Active Directory is not installed. b. This operation requires that you log on as the local Administrator, not the Administrator for Directory Services Restore Mode. c. Restore the System State as described, but in normal mode.

d. When you are prompted to restart the server after you complete the restore operation, click Yes to restart the server normally. 3. Verify Active Directory restore

Restore from backup media


To restore the server, use a good backup containing the system state or the system state and system disk. Note To restore from backup, you must log on locally to the domain controller or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restore from backup media 1. Start the computer in Directory Services Restore Mode. 2. To start the Windows Server 2003 backup utility, click Start, point to All Programs, point to Accessories, point to System Tools, and then click Backup. This procedure provides steps for restoring from backup in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page

appears, click Wizard Mode to open the Backup or Restore Wizard. 3. On the Welcome to the Backup or Restore Wizard page, click Next. 4. Click Restore files and settings, and then click Next. 5. Select System State, and then click Next. 6. On the Completing the Backup or Restore Wizard page, click Advanced. 7. In Restore files to, click Original Location, and then click Next. 8. Click Leave existing files (Recommended), and then click Next. 9. In Advanced Restore Options, select the following check boxes, and then click Next: Restore security settings

Restore junction points, but not the folders and file data they reference Preserve existing volume mount points

10. For a primary restore of SYSVOL, also select the following check box: When restoring replicated data sets, mark the restored data as the primary data for all replicas. A primary restore is required only if the domain controller that you are restoring is the only domain controller in the domain. A primary restore is required on the first domain controller that is being restored in a domain if you are restoring the entire domain or forest. 11. Click Finish. 12. When the restore process is complete, click Close, and then do one of the following: If you do not want to authoritatively restore any objects, click Yes to restart the computer. The system will restart and replicate any new information that is received since the last backup with its replication partners. If you want to authoritatively restore any objects or if you want to create an LDAP Data Interchange Format (LDIF) file to restore back-links on this domain controller, click No to remain in Directory Services Restore Mode. For information about how to proceed with authoritative restore, see Performing an Authoritative Restore of Active Directory Objects.

See Also
Restart the domain controller in Directory Services Restore Mode locally Enable Remote Desktop Create a Remote Desktop Connection Restart the domain controller in Directory Services Restore Mode Remotely Restore system state to an alternate location Performing an Authoritative Restore of Active Directory Objects

Verify Active Directory restore


After the restore is completed, use this procedure to restart the server and perform basic verification. Administrative credentials To verify Active Directory restore, you must be a member of the Domain Admins group. To verify Active Directory restore 1. After the restore operation completes, restart the computer in Start Windows Normally mode. Active Directory and Certificate Services automatically detect that they have been recovered from a backup. They perform an integrity check and reindex the database. 2. After you are able to log on to the system, browse Active Directory. Verify that all of the User objects and Group objects that were present in the directory prior to backup are restored. Similarly, verify that files that were members of a File Replication service (FRS) replica set and certificates that were issued by the Certificate Services are present.

Restoring a Domain Controller Through Reinstallation


Restoring a domain controller 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 it is valid only if another healthy domain controller exists in the same domain. This method is normally used on computers that function only as a domain controller. Restoring through reinstallation is the only method by which a domain controller that is not part of the backup set can be restored. In addition, you might choose to use this method instead of a nonauthoritative restore because backup media is inaccessible or because this method is more convenient. Restoring a domain controller through reinstallation should not be a substitute for regular backup routines. This method of restoring a domain controller requires a complete reinstallation of the operating system. It is recommended that before you install the operating system, you format the entire system disk, which will remove all information on the system disk. Ensure that any important or relevant data is moved or backed up before you perform these actions. Bandwidth is the primary consideration for restoring a domain controller through reinstallation. The bandwidth that is required is directly proportional to the size of the Active Directory database and the time in which the domain controller is required to be in a functioning state. Ideally, the existing functional domain controller should be located in the same Active Directory site as the replicating domain controller (the new domain controller) to reduce the impact on the network and the time that the reinstallation takes to complete. Note Before you restore a domain controller through reinstallation, ensure that hardware failure is not the cause of the problem. If faulty hardware is not changed, restoring through reinstallation might not solve the problems with the domain controller. Task requirements The following tools are required to perform the procedures for this task: Ntdsutil.exe Netdiag.exe Dcdiag.exe Dcpromo.exe

To complete this task, perform the following procedures: 1. If you plan to give the newly reinstalled domain controller the same name as the failed computer, use the following procedure to clean up server metadata to remove the NTDS Settings object of the failed domain controller: Clean up server metadata If you plan to give the new domain controller a different name, in addition to cleaning up server metadata, perform the following additional procedures: Delete a Server object from a site Delete a Computer object from the Domain Controllers OU 2. Install Windows Server 2003 It is assumed that you will perform a fresh installation of Windows Server 2003. Prepare for installation of the operating system by partitioning or reformatting your hard disk drive, if necessary. 3. Verify DNS registration and functionality 4. Verify communication with other domain controllers 5. Verify the availability of the operations masters 6. Install Active Directory During the installation process, replication occurs, which ensures that the domain controller has an accurate and up-to-date copy of Active Directory. You have the option to use the same information for this domain controller as the domain controller that it is replacing: site placement, domain controller name, and domain membership should remain the same. If you plan to install the domain controller under a different name, see Installing a Domain Controller in an Existing Domain. 7. Verifying Active Directory Installation

Clean up server metadata


You perform the metadata cleanup process by using Ntdsutil.exe, a command-line tool that is automatically installed on all domain controllers. Metadata cleanup removes data from Active Directory that identifies a domain controller to the replication system. On a domain controller that is running Windows Server 2003 with Service Pack 1 (SP1), metadata cleanup also removes File replication service (FRS) connections and attempts to transfer

or seize any operations master roles that the retired domain controller holds. These additional processes are performed automatically. Administrative credentials To complete this procedure, you must be a member of the Enterprise Admins group. To clean up server metadata 1. Open a command prompt. 2. Type the following command, and then press ENTER: ntdsutil 3. At the ntdsutil: prompt, type: metadata cleanup 4. Perform metadata cleanup as follows: If you are performing metadata cleanup by using the version of Ntdsutil.exe that is included with Windows Server 2003 SP1, at the metadata cleanup: prompt, type: remove selected server ServerName Or remove selected server ServerName1 on ServerName2 Value ServerName, ServerName1 Definition The distinguished name of the domain controller whose metadata you want to remove, in the form cn=ServerName,cn=Servers,cn=SiteName, cn=Sites,cn=Configuration,dc=ForestRootDomain The DNS name of the domain controller to which you want to connect and from which you want to remove server metadata

ServerName2

If you are performing metadata cleanup by using the version of Ntdsutil.exe that is included with Windows Server 2003 with no service pack, perform metadata cleanup as follows: a. At the metadata cleanup: prompt, type:

connection b. At the server connections: prompt, type: connect to server Server c. At the server connections: prompt, type:

quit d. At the metadata cleanup: prompt, type: select operation target e. At the select operation target: prompt, type: list sites A numbered list of sites appears. f. At the select operation target: prompt, type:

select site SiteNumber g. At the select operation target: prompt, type: list domains in site A numbered list of domains in the selected site appears. h. At the select operation target: prompt, type: select domain DomainNumber i. At the select operation target: prompt, type:

list servers in site A numbered list of servers in a domain and site appears. j. At the select operation target: prompt, type:

select server ServerNumber k. At the select operation target: prompt, type:

quit l. At the metadata cleanup: prompt, type:

remove selected server

Value Server

Description The DNS name of a domain controller that you want to connect to The number associated with the site of the server that you want to clean up that appears in the list The number associated with the domain of the server that you want to clean up that appears in the list The number associated with the server that you want to clean up that appears in the list

SiteNumber

DomainNumber

ServerNumber

At this point, Active Directory confirms that the domain controller was removed successfully. If you receive an error message that indicates that the object cannot be found, Active Directory might have already removed the domain controller. 5. At the metadata cleanup: and ntdsutil: prompts, type quit.

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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To delete a server object from a site 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then expand the site from which you want to delete a Server object. 3. 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. 4. Click Yes to confirm your choice.

Delete a Computer object from the Domain Controllers OU


You can use this procedure to delete the Computer object for a failed domain controller. If a domain controller fails and you cannot use the Dcpromo command to remove Active Directory, you must forcefully remove Active Directory and then clean up server metadata. When you perform Dcpromo normally, server metadata, the Computer object, and the Server object for the domain controller are deleted automatically. After you forcefully remove Active Directory, you must clean up server metadata for the failed domain controller and then delete the Server object and Computer object manually. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the domain controller that you are removing. O To delete a Computer object from the Domain Controllers organizational unit (OU) 1. Open Active Directory Users and Computers. 2. Click the Domain Controllers OU. 3. In the details pane, right-click the Computer object that is associated with the failed domain controller, click Delete, and then click Yes.

See Also
Forcing the Removal of a Domain Controller Clean up server metadata

Delete a Server object from a site

Verify DNS registration and functionality


This procedure verifies that DNS is functioning so that other domain controllers can be located. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To verify DNS registration and functionality 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:dns Note For a more detailed response from this command, add /v to the end of the command. 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 with 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 communication with other domain controllers


This procedure verifies that domain controllers can be located. Administrative Credentials To perform this procedure, you must be a member of the Domain users group in Active Directory.

To verify communication with other domain controllers 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:dsgetdc Note For a more detailed response from this command, add /v to the end of the command. 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 the availability of the operations masters


This procedure verifies that the operations masters can be located and that they are online and responding. Administrative Credentials To perform this procedure, you must be a member of the Domain users group in Active Directory. Note You can use these tests prior to installing Active Directory as well as afterward. 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. 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 test. 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 by adding /v to the end of the command to see the detailed response.

To verify the availability of the operations masters 1. Open a Command Prompt. 2. Type the following command to ensure that the operations masters can be located and then press ENTER: dcdiag /s: domaincontroller /test:knowsofroleholders /verbose 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 the 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. Press ENTER. 3. Type the following command to ensure that the operations masters are functioning properly and are available on the network: 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. Press ENTER. 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.

Install Active Directory


Use the Active Directory Installation Wizard to install Active Directory on a member server in your domain to create an additional domain controller in an existing domain. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To install Active Directory 1. Click Start, click Run, type dcpromo and then press ENTER. 2. The Active Directory Installation Wizard appears. At the Welcome screen, click

Next. 3. For Domain Controller Type, select Additional domain controller for an existing domain. Click Next. 4. 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. 5. Enter the name of the domain that you want the new domain controller to host. Click Next. 6. For 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. 7. For Shared System Volume, enter the path where you want to locate the system volume (SYSVOL). Click Next. 8. 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. 9. 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. 10. 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. Verify that this information is correct. Click Finish to close the wizard. 11. Click Restart to restart the domain controller. 12. 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, some services may be 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.

Administering Intersite Replication


This guide provides information for administering intersite replication in the Microsoft Windows Server 2003 operating system. In this guide Introduction to Administering Intersite Replication Managing Intersite Replication

Acknowledgements Published: March 2005 Applies to: Windows Server 2003 Produced by: Microsoft Windows Server User Assistance team Writer: Mary Hillman Editor: Jim Becker

Introduction to Administering Intersite Replication


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 (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, or clients no longer require the sites to discover network resources, you can remove the site and associated objects from Active Directory.

Note Managing large hub-and-spoke topology or using the SMTP intersite replication transport is beyond the scope of this documentation. Managing sites: Enables 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. Optimizes replication between domain controllers.

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 tries to set a maximum number of hops (3) between any two 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 Planning Domain Controller Capacity on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=42682). 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 all from the bridgehead servers list restores the automatic selection functionality to the ISTG.

Managing Intersite Replication


The following tasks for managing intersite replication are described in this objective: Adding a New Site Linking Sites for Replication Changing Site Link Properties Moving a Domain Controller to a Different Site Removing a Site

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 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. If a new range of Internet Protocol (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 associate 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. Task requirements The following tool is required to perform the procedures for this task: Active Directory Sites and Services

To complete this task, perform the following procedures: 1. Create a site object and add it to an existing site link 2. Associate a range of IP addresses with the site by using either of the following methods: Create a subnet object or objects and associate them with the new site

Associate an existing subnet object with the new site

3. If you are creating both a new site and a new site link, after you create the new site and add it to an existing site link, Create a site link object and add the appropriate sites. Then, remove the site from the first site link that you added it to when you created the site, if appropriate. 4. Remove the site from the site link

Create a site object and add it to an existing site link


To create a new site, you must create a Site object and add it to a site link. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To create a site object and add it to an existing site link 1. Open Active Directory Sites and Services. 2. Right-click the Sites container and then click New Site. 3. In the Name box, type the name of the site. 4. In the Link Name list, click a site link for this site, and then click OK. 5. In the Active Directory message box, read the information, and then click OK.

Create a subnet object or objects and associate them with the new site
Create a Subnet object or objects and associate them with the new site you must have the following information: The site to which the subnet is to be associated. The network address or any IP address in the range.

The subnet mask.

Active Directory Sites and Services converts this information into the subnet address. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To create a subnet object or objects and associate them with the new site 1. Open Active Directory Sites and Services. 2. Expand the Sites container, right-click Subnets, and then click New Subnet. 3. 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. 4. In the Mask box, type the subnet mask. 5. In the Site Name box, click the site to which this subnet is being associated, and then click OK.

Associate an existing subnet object with the new site


Associate an existing subnet with a site under the following conditions: When you are removing the site to which the subnet was associated.

When you have temporarily associated the subnet with a different site and want to associate it with its permanent site. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To associate an existing subnet object with the new site 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then click the Subnets container. 3. In the details pane, right-click the subnet with which you want to associate the

site, and then click Properties. 4. In the Site box, click the site with which to associate the subnet, and then click OK.

Create a site link object and add the appropriate sites


Use this procedure to create a Site Link object in the IP container and add the appropriate sites. 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. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To create a site link object 1. Open Active Directory Sites and Services. 2. Expand the Sites container and then the Inter-Site Transports container. 3. Right-click IP, and then click New Site Link. 4. In the Name box, type a name for the site link. 5. 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. 6. After selecting all of the sites that you want added to the site link, click Add, and then click OK.

Remove the site from the site link


Use Site Link properties to remove a site from a site link. Administrative Credentials

To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To remove a site from a site link 1. Open Active Directory Sites and Services. 2. Expand the Sites container and then the Inter-Site Transports container. 3. Click IP. In the details pane, right-click the site link from which you want to remove a site, and then click Properties. 4. In the Sites in this site link box, click the site you want to remove from the site link. 5. Click Remove, and then click OK.

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. Task Requirements The following tool is required to perform the procedures for this task: Active Directory Sites and Services

To complete this task, perform the following procedures: 1. Create a site link object and add the appropriate sites 2. By default, the KCC runs every 15 minutes to generate the replication topology. To generate the intersite topology immediately, perform the following two procedures:

Determine the ISTG role owner for a site Generate the replication topology on the ISTG

Create a site link object and add the appropriate sites


Use this procedure to create a Site Link object in the IP container and add the appropriate sites. 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. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To create a site link object 1. Open Active Directory Sites and Services. 2. Expand the Sites container and then the Inter-Site Transports container. 3. Right-click IP, and then click New Site Link. 4. In the Name box, type a name for the site link. 5. 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. 6. After selecting all of the sites that you want added to the site link, click Add, and then click OK.

Determine the ISTG role owner for a site


Use this procedure to view the NTDS Site Settings object properties and determine the Intersite Topology Generator (ISTG) role owner for the site. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group.

To determine the ISTG role owner for a site 1. Open Active Directory Sites and Services. 2. Click the site object whose ISTG you want to determine. 3. 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.

Generate the replication topology on the ISTG


The Knowledge Consistency Checker (KCC) runs by default every 15 minutes. If you want to initiate topology regeneration immediately, you can force the KCC to run as follows: To generate the intersite replication topology, run the KCC on the domain controller in the site that holds the ISTG role. To generate the intrasite replication topology, run the KCC on any domain controller in the site that does not hold the ISTG role. Note To generate the replication topology on the ISTG, you must first complete the procedure: Determine the ISTG role owner for a site. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To generate the replication topology on the ISTG 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then expand the site that contains the server on which you want to run the KCC. 3. Expand the Servers container, and then click the Server object for the ISTG. 4. In the details pane, right-click NTDS Settings, click All Tasks, and then click Check Replication Topology. 5. In the Check Replication Topology message box, click OK.

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. Task Requirements The following tool is required to perform the procedures for this task: Active Directory Sites and Services

To complete this task, perform the following procedures: 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 topology by performing the following two procedures: Determine the ISTG role owner for a site Generate the replication topology on the ISTG

Configure the site link schedule to identify times during which intersite replication can occur
Use the properties on the Site Link object to define when replication is allowed. Obtain the schedule from your design team. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To configure the site link schedule 1. Open Active Directory Sites and Services. 2. Expand the Sites container and the Inter-Site Transports container, and then click the IP container. 3. In the details pane, right-click the Site Link object you want to configure, and then click Properties. 4. In the SiteLinkName Properties dialog box, click Change Schedule. 5. 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. 6. Click OK twice.

Configure the site link interval to identify how often replication polling can occur during the schedule window
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 your design team. Administrative Credentials

To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To configure the site link interval 1. Open Active Directory Sites and Services. 2. Expand the Sites container and the Inter-Site Transports container, and then click the IP container. 3. In the details pane, right-click the Site Link object you want to configure, and then click Properties. 4. 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 cost to establish a priority for replication routing
When creating or modifying site links, use the object properties to configure the relative cost of using the site link. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To configure the site link cost 1. Open Active Directory Sites and Services. 2. Expand the Sites container and the Inter-Site Transports container, and then click the IP container. 3. In the details pane, right-click the Site Link object you want to configure, and then click Properties. 4. In the Cost box, specify the number for the comparative cost of using the site link, and then click OK.

Determine the ISTG role owner for a site


Use this procedure to view the NTDS Site Settings object properties and determine the Intersite Topology Generator (ISTG) role owner for the site. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To determine the ISTG role owner for a site 1. Open Active Directory Sites and Services. 2. Click the site object whose ISTG you want to determine. 3. 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.

Generate the replication topology on the ISTG


The Knowledge Consistency Checker (KCC) runs by default every 15 minutes. If you want to initiate topology regeneration immediately, you can force the KCC to run as follows: To generate the intersite replication topology, run the KCC on the domain controller in the site that holds the ISTG role. To generate the intrasite replication topology, run the KCC on any domain controller in the site that does not hold the ISTG role. Note To generate the replication topology on the ISTG, you must first complete the procedure: Determine the ISTG role owner for a site. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To generate the replication topology on the ISTG 1. Open Active Directory Sites and Services.

2. Expand the Sites container, and then expand the site that contains the server on which you want to run the KCC. 3. Expand the Servers container, and then click the Server object for the ISTG. 4. In the details pane, right-click NTDS Settings, click All Tasks, and then click Check Replication Topology. 5. In the Check Replication Topology message box, click OK.

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 might be forced to 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 Verifying Active Directory Installation.

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 the 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. Task Requirements My Network Places

DNS snap-in Active Directory Sites and Services Adsiedit.msc

To complete this task, perform the following procedures in order: 1. Change the static IP address of a domain controller 2. Create a delegation for a domain controller 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. If your forest root domain has a parent DNS domain, perform this procedure on a DNS server in the parent domain. If you just added a new domain controller to a child domain, perform this procedure on a DNS server in the DNS parent domain. By following recommended practices, the parent domain is the forest root domain. 3. Verify that an IP address maps to a subnet and determine the site association 4. Determine whether the server is a preferred bridgehead server 5. Configure the server to not be a preferred bridgehead server 6. Move the Server object to the new site

Change the static IP address of a 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. Note If you change the static IP address of a domain controller, you must also change related TCP/IP settings accordingly. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the domain controller whose IP address you are changing.

To change the static IP address of a domain controller 1. Log on locally to the domain controller whose IP address you want to change. 2. On the desktop, right-click My Network Places and then click Properties. 3. In the Network Connections dialog box, right-click Local Area Connection, and then click Properties. 4. In the Local Area Connection Properties dialog box, double-click Internet Protocol (TCP/IP). 5. In the Internet Protocol (TCP/IP) Properties dialog box, in the IP address box, type the new address. 6. In the Subnet mask box, type the subnet mask. 7. In the Default gateway box, type the default gateway. 8. In the Preferred DNS server box, type the address of the DNS server that this computer contacts. 9. In the Alternate DNS server box, type the address of the DNS server that this computer contacts if the preferred server is unavailable. 10. If this domain controller uses WINS servers, click Advanced and then, in the Advanced TCP/IP Settings dialog box, click the WINS tab. 11. If an address in the list is no longer appropriate, click the address, and then click Edit. 12. In the TCP/IP WINS Server dialog box, type the new address, and then click OK. 13. 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. 14. Click OK to close the Internet Protocol (TCP/IP) Properties dialog box.

Create a delegation for a domain controller


Use this procedure to create a delegation for a new domain controller that is also a DNS server in the parent DNS domain.

Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To create a delegation for a domain controller 1. Open the DNS snap-in. 2. Navigate to ChildDomain (where ChildDomain is the name of the child domain) in the console tree. 3. In the console tree, right-click ChildDomain, and then click Properties. 4. In the ChildDomain Properties sheet, on the Name Servers tab, click Add. 5. In the New Resource Record dialog box, in the Server fully qualified domain name (FQDN) box, type ChildDC.ChildDomain.ParentDomain (where ChildDC is the name of the new domain controller, ChildDomain is the name of the child domain, and ParentDomain is the name of the parent domain). 6. In the New Resource Record dialog box, in the IP address box, type IPAddress (where IPAddress is the IP address of the child domain controller), click Add, and then click OK.

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. Administrative Credentials

To perform this procedure, you must be a member of the Domain Users group. To verify that an IP address maps to a subnet and determine the site association 1. Log on locally or open a Terminal Services connection to the server for which you want to check the IP address. 2. On the desktop, right-click My Network Places, and then click Properties. 3. In the Network Connections dialog box, right-click Local Area Connection, and then click Properties. 4. Double-click Internet Protocol (TCP/IP). 5. Use the values in IP address and Subnet mask to calculate the subnet address and then click OK. 6. Click OK again and close the Network Connections dialog box. 7. Open Active Directory Sites and Services. 8. Expand the Sites container, and then click the Subnets container. 9. In the Name column in the details pane, find the Subnet object that matches the subnet address. 10. 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.

Determine whether the server 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To view the list of preferred bridgehead servers 1. Click Start, click Run, type the following command and then press ENTER:

adsiedit.msc 2. In ADSI Edit, expand the Configuration Container and then expand CN=Configuration,DC=ForestRootDomainName, CN=Sites, and CN=Inter-Site Transports. 3. Right-click CN=IP and then click Properties. 4. In the Attributes box, double-click bridgeheadServerListBL. 5. If any preferred bridgehead servers are selected in any site in the forest, the Values box displays the distinguished name for each server object that is currently selected as a preferred bridgehead server.

Configure the server to not be a preferred bridgehead server


Use the Server object properties to remove a preferred bridgehead server from the IP transport. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To configure the server to not be a preferred bridgehead server 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then expand the site of the preferred bridgehead server. 3. Expand the Servers node to display the list of domain controllers currently configured for that site. 4. Right-click the server you want to remove, and then click Properties. 5. 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.

Move the Server object to the new 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. Before performing this procedure, verify that the IP address maps to the target site. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To move the server object to the new site 1. Open Active Directory Sites and Services. 2. Expand the Sites container and the site in which the server object resides. 3. Expand the Servers container to display the domain controllers that are currently configured for that site. 4. Right-click the Server object you want to move, and then click Move. 5. In the Site Name box, click the destination site, and then click OK. 6. Expand the Site object to which you moved the server, and then expand the Servers container. 7. Verify that an object for the server you moved exists. 8. 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 sitespecific 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.

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. 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. 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 is running on a domain controller, these applications create Child objects beneath the Server object. In addition, a server running Message Queuing that is not a domain controller and is configured to be a routing server running Message Queuing 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: 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 objects: 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 removing a site, you need to consider the implications. 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.

Task Requirements The following tool is required to perform the procedures for this task: Active Directory Sites and Services

To complete this task, perform the following procedures: 1. Determine whether a Server object has child objects 2. Delete a Server object from a site 3. Delete the Site Link object 4. Associate the subnet or subnets with the appropriate site 5. Delete the Site object 6. To avoid replication errors on bridgehead servers in other sites that received replication from the site that has been removed, generate the intersite topology in those sites by performing the following two procedures: Determine the ISTG role owner for a site Generate the replication topology on the ISTG

Determine whether a Server object has child objects


After Active Directory is properly installed on a domain controller, the Server object for the domain controller will have a Child NTDS-Settings object. Other applications that are running on domain controllers can also publish Child objects. Prior to deleting a Server object from the Servers container for a site, verify that the Server object has no Child objects. If a Child object appears, do not delete the Server object. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To determine whether a server object has child objects 1. Open Active Directory Sites and Services. 2. Expand the Sites container and expand the site of the Server object. 3. Expand the Servers container, and then expand the Server object to view any Child objects.

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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To delete a server object from a site 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then expand the site from which you want to delete a Server object. 3. 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. 4. Click Yes to confirm your choice.

Delete the Site Link object


Use the following procedure to delete a Site Link object. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To delete a site link object 1. Open Active Directory Sites and Services.

2. Expand the Sites container and the Inter-Site Transports container, and then click the IP container. 3. In the details pane, right-click the Site Link object you want to delete, and then click Delete. 4. Click Yes to confirm your choice.

Associate the subnet or subnets with the appropriate site


Associate an existing subnet with a site under the following conditions: When you are removing the site to which the subnet was associated.

When you have temporarily associated the subnet with a different site and want to associate it with its permanent site. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To associate the subnet or subnets with the appropriate site 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then click the Subnets container. 3. In the details pane, right-click the subnet with which you want to associate the site, and then click Properties. 4. In the Site box, click the site with which to associate the subnet, and then click OK. If the IP addresses are no longer in use, delete the Subnet object or objects with which the addresses are associated.

Delete the 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. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To delete the site object 1. Open Active Directory Sites and Services and click the Sites container. 2. In the details pane, right-click the site you want to delete, and then click Delete. 3. Click Yes to confirm your choice. 4. In the Active Directory message box, read the information, and then click Yes to delete the site and its Servers container object.

Determine the ISTG role owner for a site


Use this procedure to view the NTDS Site Settings object properties and determine the Intersite Topology Generator (ISTG) role owner for the site. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To determine the ISTG role owner for a site 1. Open Active Directory Sites and Services. 2. Click the site object whose ISTG you want to determine. 3. 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.

Generate the replication topology on the ISTG


The Knowledge Consistency Checker (KCC) runs by default every 15 minutes. If you want to initiate topology regeneration immediately, you can force the KCC to run as follows: To generate the intersite replication topology, run the KCC on the domain controller in the site that holds the ISTG role. To generate the intrasite replication topology, run the KCC on any domain controller in the site that does not hold the ISTG role. Note To generate the replication topology on the ISTG, you must first complete the procedure: Determine the ISTG role owner for a site. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To generate the replication topology on the ISTG 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then expand the site that contains the server on which you want to run the KCC. 3. Expand the Servers container, and then click the Server object for the ISTG. 4. In the details pane, right-click NTDS Settings, click All Tasks, and then click Check Replication Topology. 5. In the Check Replication Topology message box, click OK.

Administering the Active Directory Database


This guide provides information for administering the Active Directory database in the Microsoft Windows Server 2003 operating system. In this guide

Introduction to Administering the Active Directory Database Managing the Active Directory Database

Acknowledgements Published: March 2005 Applies to: Windows Server 2003 Produced by: Microsoft Windows Server User Assistance team Writer: Mary Hillman Editor: Jim Becker

Introduction to Administering the Active Directory 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 Active Directory database is a self-maintained system and requires no daily maintenance, other than regular backup, during ordinary operation. However, it may need to be managed if the following conditions occur: Low disk space Pending or current hardware failure

A need to recover physical space following bulk deletion or removal of the global catalog Monitor free disk space on the partition or partitions that store the directory database and logs. The following are the recommended parameters for free space: 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.

During ordinary operation, the customer will delete objects from Active Directory. When an object is deleted, it results in white space (or unused space) being created in the database. On a regular basis, the database will consolidate this white space through a process called defragmentation, and this white space will be reused when new objects are added (without adding any size to the file itself). This automatic online defragmentation redistributes and retains white space for use by the database, but does not release it to the file system. Therefore, the database size does not shrink, even though objects might be deleted. In cases where the 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 large amounts of white space in the database. 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. Managing the Active Directory database also allows you to upgrade or replace the disk on which the database or log files are stored or to move the files to a different location, either permanently or temporarily. 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 Back up system state. 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. Note NTFS disk compression is not supported for the database and log files.

Managing the Active Directory Database


The following tasks for managing the Active Directory database are described in this objective: Relocating Active Directory Database Files

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

Relocating Active 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. If you are not using Ntdsutil.exe when moving files to a different partition, you will need to manually update the registry. If the path to the database file or log files will change 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 remains 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. 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: Database backup path Digital Signature Algorithm (DSA) database file

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: Database log files path

Disk space requirements for relocating Active Directory database files


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 which 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 which 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. Therefore, adding additional space according to anticipated growth is recommended. Task Requirements The following tools are required to perform the procedures for this task: net use dir

xcopy Ntdsutil.exe Backup software Windows Explorer

Note 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 Relocating SYSVOL Manually. To complete this task, perform the following procedures: Note The domain controller will not be available during the time in which files are being moved and until the move is verified. Ensure that alternate domain controllers are available during the file relocation to handle the capacity. 1. Determine the size and location of the Active Directory database by using one of the following procedures: Determine the database size and location online Determine the database size and location offline

2. Compare the size of the directory database files to the volume size 3. Back up system state System state includes the database file and log files as well as SYSVOL and Net Logon 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 by using one of the following methods: Restart the domain controller in Directory Services Restore Mode locally Restart the domain controller in Directory Services Restore Mode Remotely

5. Move or copy the directory database and log files by performing one of the following procedures: Move the directory database and log files to a local drive Copy the directory database and log files to a remote share

The shared folder on a remote drive must have 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. 6. Back up system state

Determine the database size and location online


When determining the database size and location online, the size is reported in bytes. 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. Important 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. For information about determining database size offline, see Determine the database size and location offline. 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 Active 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To determine the database size and location online 1. 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. 2. 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 01/29/2002 11:04 AM 01/28/2002 03:03 PM 01/29/2002 10:29 AM 01/29/2002 10:29 AM 01/29/2002 10:29 AM 01/29/2002 10:29 AM 01/28/2002 02:54 PM 01/28/2002 02:54 PM 7 File(s) 3 Dir(s) <DIR> <DIR> <DIR> . .. Drop

8,192 edb.chk 10,485,760 edb.log 10,485,760 edb00001.log 14,696,448 ntds.dit 10,485,760 res1.log 10,485,760 res2.log

58,761,216 bytes 779,284,480 bytes free

Determine the database size and location offline


When determining the database size and location offline, the size is reported in megabytes (MB). Use this method if the domain controller is already started in Directory Services Restore Mode. Important 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. For information about determining database size offline, see Determine the database size and location offline. 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 Active 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. Administrative Credentials To perform this procedure, you must be an administrator on the local computer. To determine the database size and location offline 1. With the domain controller in Directory Services Restore Mode, open a command prompt, type ntdsutil and then press ENTER 2. At the ntdsutil: prompt, type files and then press ENTER. 3. At the file maintenance: prompt, type info and press ENTER. 4. At the file maintenance: prompt, type quit and then press ENTER. Type quit and then press ENTER again to quit Ntdsutil.exe.

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. 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. Administrative Credentials If you are online when comparing the size of the directory database files, you must be a member of the Domain Users group. If you are offline, you must be an administrator on the local computer.

To compare the size of the directory database files to the volume size 1. In Windows Explorer, click My Computer. 2. On the View menu, click Details. 3. In the Name column in the details pane, locate the volume. Make a note of the value in the Total Size column. 4. Navigate to the folder that stores the database file, the log files, or both. 5. Right-click the folder, and then click Properties. Make a note of the value in Size on disk. 6. If the volume includes SYSVOL, navigate to that folder and repeat step 5. 7. 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. 8. If other files are present, move those files and reassess the disk space on the volume.

Back up system state


Ntbackup.exe provides simple and advanced options for backing up Active Directory components. When you back up system state, you can choose to include or exclude system-protected boot files. System-protected boot files are not used for installations from restored backup media. When the backup file that you create is to be used for additional domain controller installations, you can clear the advanced option to back up systemprotected files. Clearing this option decreases the size of the .bkf file, as well as the time required to back up, restore, and copy the system state files. Use these procedures to back up the system state only. These procedures do not back up the system disk or any other data on the domain controller except for the system-protected files. Use the first procedure, "To back up system state including system-protected files," for routine system state backup. Use the second procedure, "To back up system state excluding system-protected files," if you want to create a smaller backup that is effective for installing domain controllers from restored backup media.

Note To back up system state, you must log on locally to the domain controller, or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform the following two procedures, you must be a member of the Domain Admins group or a member of the Backup Operators group. To back up system state including system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. This procedure provides steps for backing up in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard. 2. On the Welcome to the Backup or Restore Wizard page, click Next. 3. Select Back up files and settings, and then click Next. 4. Select Let me choose what to back up, and then click Next. 5. In the Items to Back Up window, double-click My Computer. 6. In the expanded list below My Computer, check System State, and then click Next. 7. Select a location to store the backup: If you are backing up to a file, type the path and file name for the backup (.bkf) file (or click Browse to find a folder or file). If you are backing up to a tape unit, choose the tape that you want to use. Note You should not store the backup on the local hard drive. Instead, store it in a location, such as a tape drive, away from the computer that you are backing up. 8. Type a name for this backup according to the recommendations in Backing Up Active Directory Components, and then click Next. 9. On the last page of the wizard, click Advanced. 10. Do not change the default options for Type of Backup. Normal should be

selected, and the check box for Backup migrated remote storage data should remain cleared. Click Next. 11. Select Verify data after backup, and then click Next. 12. In the Backup Options dialog box, select a backup option, and then click Next. 13. If you are replacing the existing backups, select the option to allow only the owner and administrator access to the backup data and to any backups that are appended to this medium, and then click Next. 14. In the When to back up box, select the appropriate option for your needs, and then click Next. 15. If you are satisfied with all of the options that are selected, click Finish to perform the backup operation according to your selected schedule. Note The system state can also be backed up by using Ntbackup from a command line with appropriate parameters. For more information, at a command prompt type ntbackup /?. The following procedure produces a smaller .bkf file that does not include system boot files. By using this procedure, you can reduce the time that is required to perform the backup and subsequent restore, as well as the amount of disk space that is required. This method is recommended when the restored backup is to be used for installing additional domain controllers. To back up system state excluding system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. 2. On the Welcome to the Backup or Restore Wizard page, click Advanced Mode, and then click the Backup tab. 3. In the console tree, select the System State check box. 4. In Backup media or file name, type a name for this backup according to the recommendations in Backing Up Active Directory Components. 5. Click Start Backup, and then click Advanced. 6. Clear the Automatically back up System Protected Files with the System State check box, and then click OK. 7. Click Start Backup.

See Also
Enable Remote Desktop Create a Remote Desktop Connection

Restart the domain controller in Directory Services Restore Mode locally


If you have physical access to a domain controller, you can restart the domain controller in Directory Services Restore Mode locally. Restarting in Directory Services Restore Mode takes the domain controller offline. In this mode, the server is not functioning as a domain controller. When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restart the domain controller in Directory Services Restore Mode locally 1. Restart the domain controller. 2. When the screen for selecting an operating system appears, press F8. 3. On the Windows Advanced Options menu, select Directory Services Restore Mode. 4. When you are prompted, log on as the local administrator.

See Also
Restart the domain controller in Directory Services Restore Mode Remotely

Restart the domain controller in Directory Services Restore Mode Remotely


If Remote Desktop is enabled on a domain controller, you can use Remote Desktop Connection to connect to the domain controller remotely. Remote Desktop Connection (formerly known as the Terminal Services client) is installed by default on all Windows Server 2003 family operating systems. If you use Remote Desktop Connection to connect to a domain controller remotely and you want to restart the domain controller in Directory Services Restore Mode, you must first modify the Boot.ini file on the remote server so that you do not lose the connection when the domain controller restarts. When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restart the domain controller in Directory Services Restore Mode remotely 1. Use Remote Desktop Connection to connect to the domain controller that you want to restart in Directory Services Restore Mode. 2. Right-click My Computer, click Properties, and then click the Advanced tab. 3. Click Settings for startup and recovery. 4. Click the Edit button to edit the startup options file. 5. 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 and Windows Server 2003.

6. Save the modified Boot.ini file, and then close Notepad. 7. On the Start menu, click Shut Down, and then click Restart. During the restart process, the Terminal Services client reports that the session is disconnected. Caution Be sure to click Restart and not Shut Down at this step. If you click Shut Down, you cannot restart the domain controller remotely. 8. Wait until the restart process completes on the remote domain controller, and then reconnect the client session. 9. When the client session is reconnected, log on as the local administrator. 10. Right-click My Computer, click Properties, and then click the Advanced tab. 11. Click Settings for startup and recovery. 12. Click the Edit button to edit the startup options file. 13. Delete the /SAFEBOOT:DSREPAIR switch from the default entry in the Boot.ini file, save the file, and then close Notepad. Important If you restart the domain controller before you modify the Boot.ini file, the domain controller remains offline. The Boot.ini file is now returned to its original state, which starts the domain controller normally.

See Also
Enable Remote Desktop Create a Remote Desktop Connection Restart the domain controller in Directory Services Restore Mode locally

Move the directory database and log files to a local drive


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. 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. Administrative Credentials To perform this procedure, you must be an Administrator on the local computer. To move the directory database and log files to a local drive 1. 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. 2. Run the dir command and make a note of the current size and location of the Ntds.dit file. 3. At the command prompt, type ntdsutil and then press ENTER. 4. At the ntdsutil: prompt, type files and then press ENTER. 5. 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 To move the log files, type:

move logs to drive:\directory where Drive:\directory specifies 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").

6. After the move completes, at the file maintenance: prompt, type quit and press ENTER. Type quit again and press ENTER to quit Ntdsutil.exe. 7. 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. 8. 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. If the path to the database file or log files has not changed, go to step 10. 9. 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: a. 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 security identifiers (SIDs). Remove any such accounts. k. Click OK to close Properties.

10. At the command prompt, type ntdsutil and then press ENTER. 11. At the ntdsutil: prompt, type files and then press ENTER. 12. At the file maintenance: prompt, type integrity and then press ENTER. If the integrity check fails, perform semantic database analysis with a fixup record. 13. If the integrity check succeeds, type quit and press ENTER to quit the file maintenance: prompt. Type quit again and press ENTER to quit Ntdsutil.exe. 14. 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: a. Restart the domain controller in Directory Services Restore Mode. b. 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: Event ID 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. Event ID 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.

Copy the directory database and log files to a remote share


When copying any database files from the local computer, always copy both the database file and the log files. 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 the xcopy command 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. 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 files necessary to restore the directory service are maintained. Administrative Credentials To perform this procedure, you must be an Administrator on the local computer. To copy the directory database and log files to a remote share and back to the local computer 1. 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. 2. Run the dir command and make a note of the current size and location of the Ntds.dit file and the log files. 3. 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. 4. 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 database, 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 database 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. 5. 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. 6. At this point, you can safely destroy data on the original local drive. 7. After the destination drive is prepared, re-establish a connection to the network drive as described in step 3, if necessary. 8. Copy the database and log files from the remote shared folder back to the original location on the domain controller. 9. At the command prompt, type ntdsutil and then press ENTER. 10. At the ntdsutil: prompt, type files and then press ENTER. 11. At the file maintenance: prompt, type integrity and then press ENTER. 12. If the integrity check fails, perform semantic database analysis with a fixup record. 13. If the integrity check succeeds, type quit and press ENTER to quit the file maintenance: prompt. Type quit again and press ENTER to quit Ntdsutil.exe. 14. 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: 1. Restart the domain controller in Directory Services Restore Mode.

2. 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: Event ID 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. Event ID 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.

Returning Unused Disk Space from the Active Directory Database to the File System
During ordinary operation, the white space in the Active 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), or 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: Event IDs 700 and 701: report when online defragmentation begins and ends, respectively.

Event ID 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. Task requirements The following tools are required to perform the procedures for this task: Regedit.exe Backup software Ntdsutil.exe

To complete this task, perform the following procedures: 1. Change the garbage collection logging level to 1 2. Back up system state 3. Use one of the following procedures: Restart the domain controller in Directory Services Restore Mode locally

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

If you are using Remote Desktop Connection for remote administration, you can restart the domain controller remotely 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

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. The garbage collection logging level is an NTDS diagnostics setting in the registry. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group. 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 Introduction to Administering Active Directory Backup and Restore. To change the garbage collection logging level 1. Click Start, click Run, type regedit and then press ENTER. 2. In Registry Editor, navigate to the Garbage Collection entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnosti cs 3. Double-click Garbage Collection, and for the Base, click Decimal. 4. In the Value data box, type 1, and then click OK.

Back up system state


Ntbackup.exe provides simple and advanced options for backing up Active Directory components. When you back up system state, you can choose to include or exclude system-protected boot files. System-protected boot files are not used for installations from restored backup media. When the backup file that you create is to be used for additional domain controller installations, you can clear the advanced option to back up systemprotected files. Clearing this option decreases the size of the .bkf file, as well as the time required to back up, restore, and copy the system state files.

Use these procedures to back up the system state only. These procedures do not back up the system disk or any other data on the domain controller except for the system-protected files. Use the first procedure, "To back up system state including system-protected files," for routine system state backup. Use the second procedure, "To back up system state excluding system-protected files," if you want to create a smaller backup that is effective for installing domain controllers from restored backup media. Note To back up system state, you must log on locally to the domain controller, or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform the following two procedures, you must be a member of the Domain Admins group or a member of the Backup Operators group. To back up system state including system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. This procedure provides steps for backing up in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard. 2. On the Welcome to the Backup or Restore Wizard page, click Next. 3. Select Back up files and settings, and then click Next. 4. Select Let me choose what to back up, and then click Next. 5. In the Items to Back Up window, double-click My Computer. 6. In the expanded list below My Computer, check System State, and then click Next. 7. Select a location to store the backup: If you are backing up to a file, type the path and file name for the backup (.bkf) file (or click Browse to find a folder or file). If you are backing up to a tape unit, choose the tape that you want to use. Note

You should not store the backup on the local hard drive. Instead, store it in a location, such as a tape drive, away from the computer that you are backing up. 8. Type a name for this backup according to the recommendations in Backing Up Active Directory Components, and then click Next. 9. On the last page of the wizard, click Advanced. 10. Do not change the default options for Type of Backup. Normal should be selected, and the check box for Backup migrated remote storage data should remain cleared. Click Next. 11. Select Verify data after backup, and then click Next. 12. In the Backup Options dialog box, select a backup option, and then click Next. 13. If you are replacing the existing backups, select the option to allow only the owner and administrator access to the backup data and to any backups that are appended to this medium, and then click Next. 14. In the When to back up box, select the appropriate option for your needs, and then click Next. 15. If you are satisfied with all of the options that are selected, click Finish to perform the backup operation according to your selected schedule. Note The system state can also be backed up by using Ntbackup from a command line with appropriate parameters. For more information, at a command prompt type ntbackup /?. The following procedure produces a smaller .bkf file that does not include system boot files. By using this procedure, you can reduce the time that is required to perform the backup and subsequent restore, as well as the amount of disk space that is required. This method is recommended when the restored backup is to be used for installing additional domain controllers. To back up system state excluding system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. 2. On the Welcome to the Backup or Restore Wizard page, click Advanced Mode, and then click the Backup tab.

3. In the console tree, select the System State check box. 4. In Backup media or file name, type a name for this backup according to the recommendations in Backing Up Active Directory Components. 5. Click Start Backup, and then click Advanced. 6. Clear the Automatically back up System Protected Files with the System State check box, and then click OK. 7. Click Start Backup.

See Also
Enable Remote Desktop Create a Remote Desktop Connection

Restart the domain controller in Directory Services Restore Mode locally


If you have physical access to a domain controller, you can restart the domain controller in Directory Services Restore Mode locally. Restarting in Directory Services Restore Mode takes the domain controller offline. In this mode, the server is not functioning as a domain controller. When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restart the domain controller in Directory Services Restore Mode locally 1. Restart the domain controller. 2. When the screen for selecting an operating system appears, press F8. 3. On the Windows Advanced Options menu, select Directory Services

Restore Mode. 4. When you are prompted, log on as the local administrator.

See Also
Restart the domain controller in Directory Services Restore Mode Remotely

Restart the domain controller in Directory Services Restore Mode Remotely


If Remote Desktop is enabled on a domain controller, you can use Remote Desktop Connection to connect to the domain controller remotely. Remote Desktop Connection (formerly known as the Terminal Services client) is installed by default on all Windows Server 2003 family operating systems. If you use Remote Desktop Connection to connect to a domain controller remotely and you want to restart the domain controller in Directory Services Restore Mode, you must first modify the Boot.ini file on the remote server so that you do not lose the connection when the domain controller restarts. When you start Windows Server 2003 in Directory Services Restore Mode, the local Administrator account is authenticated by the local Security Accounts Manager (SAM) database. Therefore, logging on requires that you use the local administrator password, not an Active Directory domain password. This password is set during Active Directory installation when you provide the password for Directory Services Restore Mode. Administrative credentials To perform this procedure, you must provide the Administrator password for Directory Services Restore Mode. To restart the domain controller in Directory Services Restore Mode remotely 1. Use Remote Desktop Connection to connect to the domain controller that you want to restart in Directory Services Restore Mode. 2. Right-click My Computer, click Properties, and then click the Advanced tab. 3. Click Settings for startup and recovery. 4. Click the Edit button to edit the startup options file.

5. 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 and Windows Server 2003. 6. Save the modified Boot.ini file, and then close Notepad. 7. On the Start menu, click Shut Down, and then click Restart. During the restart process, the Terminal Services client reports that the session is disconnected. Caution Be sure to click Restart and not Shut Down at this step. If you click Shut Down, you cannot restart the domain controller remotely. 8. Wait until the restart process completes on the remote domain controller, and then reconnect the client session. 9. When the client session is reconnected, log on as the local administrator. 10. Right-click My Computer, click Properties, and then click the Advanced tab. 11. Click Settings for startup and recovery. 12. Click the Edit button to edit the startup options file. 13. Delete the /SAFEBOOT:DSREPAIR switch from the default entry in the Boot.ini file, save the file, and then close Notepad. Important If you restart the domain controller before you modify the Boot.ini file, the domain controller remains offline. The Boot.ini file is now returned to its original state, which starts the domain controller normally.

See Also
Enable Remote Desktop Create a Remote Desktop Connection

Restart the domain controller in Directory Services Restore Mode locally

Compact the directory database file (offline defragmentation)


As part of the offline defragmentation procedure, check directory database integrity. 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 networkmapped 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. Note To perform this procedure, the domain controller must be started in Directory Services Restore Mode. Administrative Credentials To perform this procedure, you must be an administrator on the local domain controller. At the remote location, you must have Read and Write permissions on the destination drive and the shared folder. 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. To perform offline defragmentation of the directory database 1. 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. 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. 2. Type the following command at a command prompt and then press ENTER: ntdsutil 3. At the ntdsutil: prompt, type files and then press ENTER. 4. At the file maintenance: prompt, type compact to drive:\ LocalDirectoryPath (where drive:\ LocalDirectoryPath is the path to a location on the local computer) and then press ENTER. 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. 5. If defragmentation completes successfully, type quit and press ENTER to quit the file maintenance: prompt. Type quit again and press ENTER 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. 6. If defragmentation succeeds with no errors, then follow the Ntdsutil.exe onscreen instructions to: a. 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. b. 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. c. Manually copy the compacted database file to the original location, as follows: copy temporaryDrive:\ntds.dit originalDrive:\pathToOriginalDatabaseFile\ntds.dit 7. Type ntdsutil and then press ENTER. 8. At the ntdsutil: prompt, type files and then press ENTER. 9. 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.3. Repeat steps 6.3 through step 9. If the integrity check fails again: -or Copy the original version of the Ntds.dit file that you preserved in step 6.2. to the original database location and repeat the offline defragmentation procedure. 10. If the integrity check succeeds, proceed as follows: If the initial compact to command failed, go back 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 type quit and press ENTER again to quit Ntdsutil.exe. 11. 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: 1. Restart the domain controller in Directory Services Restore Mode. 2. Check the errors in Event Viewer. Contact Microsoft Product Support Services.

If the following events are logged in Event Viewer on restarting the domain controller, respond to the events as follows: Event ID 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. Event ID 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. 3. Check database integrity and then proceed as follows: If the integrity check fails, try repeating step 6.3 through step 9 above, and then repeat the integrity check. If the integrity check fails again: -or Copy the original version of the Ntds.dit file that you preserved in step 6.2. to the original database location and repeat the offline defragmentation procedure. If the integrity check succeeds, perform semantic database analysis with fixup. 4. If semantic database analysis with fixup succeeds, quit Ntdsutil.exe and restart the domain controller normally. If semantic database analysis with fixup fails, contact Microsoft Product Support Services. Contact Microsoft Product Support Services.

If database integrity check fails, 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. Note To perform this procedure, the domain controller must be started in Directory Services Restore Mode. Administrative Credentials To perform this procedure, you must be an administrator on the local computer.

To perform semantic database analysis with fixup 1. In Directory Services Restore Mode, open a Command Prompt. 2. Type the following command and then press ENTER: ntdsutil: 3. At the ntdsutil: prompt, type semantic database analysis and then press ENTER. 4. At the semantic checker: prompt, type verbose on and then press ENTER. 5. 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. Caution 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.

Administering Domain Controllers


This guide provides information for administering Active Directory domain controllers in the Microsoft Windows Server 2003 operating system. In this guide Introduction to Administering Domain Controllers Managing Domain Controllers

Acknowledgements Published: March 2005 Applies to: Windows Server 2003

Produced by: Microsoft Windows Server User Assistance team Writer: Shala Brandolini Editor: Jim Becker

Introduction to Administering Domain Controllers


Although installed domain controllers require little management, your overall operations environment might require change-related tasks such as adding or removing domain controllers, including managing the preparation and shipment of domain controllers to remote sites. 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 Add domain controllers to remote sites

Installing and Removing Active Directory


To create a new domain controller, install Active Directory on a computer that is running Windows Server 2003 or Windows Server 2003 with Service Pack 1 (SP1). Installing domain controllers to create a forest and new domains is a deployment task that you perform when you initially deploy your forest, and it is beyond the scope of this guide. However, as your forest grows, you might need to add more domain controllers to existing domains. There are several reasons for adding a new domain controller. Additional applications (which are Active Directoryintegrated as opposed to running on domain controllers) might be required to meet increased capacity requirements, provide upgrades and fault tolerance, and reduce failures. You might add a new site where users require a domain controller for logging on to the domain. For more information about criteria and best practices for deploying domain controllers, see Designing and Deploying Directory and Security Services on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=45801). When a domain controller is no longer needed, remove Active Directory. The process of removing Active Directory involves steps similar to the steps for installation. You run many of the same tests before you remove the directory as you ran before you installed 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 use a procedure that forces Active Directory removal and then take additional steps to remove the server object and its metadata from the directory.

Renaming Domain Controllers


You often need to rename a domain controller for organizational or administrative reasons or when the computer hardware must be replaced. Renaming a domain controller requires that Domain Name System (DNS) resource records be updated with the new Internet Protocol (IP)-to-host name mappings and that service principal names (SPNs) replicate to all domain controllers in the domain. You must also update File Replication service (FRS) objects.

Adding Domain Controllers to Remote Sites


If enough directory users are employed in a remote site, especially in a site that has slow connectivity to the hub site, you might need to add a domain controller to the site to provide directory access for logons and searches. Specifically, you can either install a domain controller in the hub site and ship it to the site or install the domain controller in the remote site. When you install the domain controller in the remote site, Active Directory must be sourced in one of two ways: By Active Directory replication over the wide area network (WAN) link Directly from restored backup media

Assuming that the remote site is connected to a hub site by a WAN link and does not contain a domain controller for the domain, you might want to avoid the additional time and the performance impact of replicating the full replica of Active Directory over the WAN when you add a new domain controller to the remote site. In this case, you can use backup media to install Active Directory. If you want to install a domain controller from backup media, both the source of the backup and the target server that is to be promoted to a domain controller must be running Windows Server 2003 or Windows Server 2003 with SP1, and the operating system of the source of the backup and the target server must be the same. The hardware platform (32bit or 64-bit) of the two computers must also match. Restoring from backup media eliminates the need to use replication to create the Active Directory replica on the new domain controller.

Managing Domain Controllers


Managing domain controllers involves the following tasks: Create an additional domain controller in an existing domain. This task involves preparation steps of gathering information and configuring the TCP/IP and Domain Name System (DNS) client settings. You can use the following methods to install Active Directory to create an additional domain controller in an existing domain: Run the Active Directory Installation Wizard, and use Active Directory replication to create the Active Directory replica and File Replication service (FRS) replication to create the System Volume (Sysvol) replicas. Run the Active Directory Installation Wizard, and use restored system state backup media to create the Active Directory and Sysvol replicas. Create an answer file and use the Unattend.txt file to provide the information that the Active Directory Installation Wizard requires. Perform tests to verify that Active Directory is properly installed and the domain controller is functioning. Add domain controllers to remote sites. When you prepare and ship an additional domain controller to a remote site, you can either install the domain controller before shipping or install the domain controller in the remote site. When you install a domain controller in a hub site or staging site before shipment, you must disconnect the domain controller for a period, which requires careful preparation. When you reconnect the domain controller, Active Directory replication brings the domain controller up to date. When you install the domain controller in the remote site, you can use a restored system state backup to avoid having to replicate Active Directory over a wide area network (WAN) link. Remove Active Directory from (decommission) a properly functioning domain controller. This task includes first removing operations master roles (also known as flexible single-master operation (FSMO) roles) and the global catalog, if necessary. Force the removal of a nonfunctioning domain controller from a domain. If a domain controller is not functioning properly on the network, the Active Directory Installation Wizard cannot contact other domain controllers and DNS servers that are required for Active Directory removal. In this case, a special version of the wizard can be invoked to forcefully remove objects that represent the server as a domain controller from Active Directory.

Rename a domain controller. You can now rename a domain controller without removing Active Directory. New functionality is available in the Netdom tool when the domain functional level is Windows Server 2003. This new functionality provides better preparation for DNS and service recognition of the new domain controller name. You can also use System Properties, which does not require a domain functional level and does not provide the same preparation, but which relies solely on replication to update the domain controller DNS name and service principal name (SPN). This method can result in a longer delay before clients can use the renamed domain controller. In addition, to protect domain controllers from infection by viruses that can corrupt directory data or cause software or hardware failure, an integral step in installing any domain controller is to install antivirus software.

Managing Antivirus Software on Domain Controllers


Because domain controllers provide critical services to their clients, it is crucial to minimize the risk of disruption of these services caused by malicious code. Antivirus software is the generally accepted way to mitigate the risk of such malevolent activity. However, one cannot simply install the antivirus software (from any vendor) on a domain controller and tell it to scan everything. Instead, it must be installed in a manner that mitigates the risk to the highest possible level while not interfering with the performance of the domain controllers in performing their directory service duties. Installing effective antivirus software on domain controllers minimizes the risk that their activities will be disrupted by malicious code.

Guidelines for Managing Antivirus Software on Domain Controllers


Follow the guidelines established by your antivirus software vendor. Note Verify that the antivirus software you are adding is confirmed to work on domain controllers. The following recommendations are general and should not be construed as more important than the specific antivirus software vendors own recommendations. These guidelines must be followed for correct Active Directory and FRS operation.

Note Test the chosen antivirus software solution thoroughly in a lab environment to ensure that the software does not compromise the stability of the system. Antivirus software must be installed on all domain controllers in the enterprise. Ideally, such software should also be installed on all other server and client systems that have to interact with the domain controllers. Catching the virus at the earliest point, at the firewall, or the client system on which the virus is first introduced is bestthat will prevent the virus from ever reaching the infrastructure systems upon which all clients depend. Use a version of antivirus software that is confirmed to work with Active Directory and uses the correct APIs for accessing files on the server. Older versions of most vendors software inappropriately modified file metadata as it was scanned, causing the FRS replication engine to think the file was changed and to schedule it for replication. Newer versions prevent this problem. For more information about antivirus software versions and FRS, see article 815263, "Antivirus, backup, and disk optimization programs that are compatible with the File Replication service" in the Microsoft Knowledge Base on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkID=4441), and see the vendor-specific sites for compliant versions. Prevent the use of domain controller systems as general workstations. Users should not be using a domain controller to surf the Web or perform any other activities that could allow the introduction of malicious code. When possible, do not use the domain controller as a file sharing server. Virus scanning software must be run against all files in those shares and could place an unsatisfactory load on the processor and memory resources of the server.

Files Not at Risk of Infection


Exclude the following files and folders from being scanned. These files are not at risk of infection and including them could cause serious performance problems due to file locking and excessive replication between domain controllers. Furthermore, they may cause Active Directory and FRS to work improperly, causing Active Directory or FRS data loss. Where a specific set of files is identified by name, exclude only those files rather than the entire folder. In some cases, the entire folder must be excluded. Do not exclude any of these based on the file name extension (that is, do not exclude all files with a .dit extension). Microsoft has no control over other files that might choose to use the same extension as those shown here. AV software must not modify any data files in the logs, database, and/or DSA working directories specified below. Active Directory and related files:

Main NTDS database files. The location of these files is specified in:

HKLM\System\Services\NTDS\Parameters\DSA Database File Default location is %windir%\ntds. The file to be excluded is: NTDS.dit (on Windows 2000). Active Directory transaction log files. The log directory on any given server is specified in: HKLM\System\Services\NTDS\Parameters\Database Log Files Path Default location is %windir%\ntds. The specific files to be excluded are: EDB*.log (notice the wildcardthere can be several) RES1.log RES2.log

NTDS Working folder specified in:

HKLM\System\Services\NTDS\Parameters\DSA WorkingDirectory Specific files to be excluded are: TEMP.edb EDB.chk

SYSVOL files FRS Working Directory specified in:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\ Working Directory Files to be excluded: FRS Working Dir\jet\sys\edb.chk FRS Working Dir\jet\ntfrs.jdb FRS Working Dir\jet\log\*.log

FRS Database Log files specified in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\D B Log File Directory Default location is %windir%\ntds. Files to be excluded:

FRS Working Dir\jet\log\*.log (if registry key is not set) DB Log File Directory\log\*.log (if registry key is set)

FRS Replica_root files specified in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\R eplica Sets\GUID\Replica Set Root Staging directory found in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\R eplica Sets\GUID\Replica Set Stage FRS Preinstall directory located at:

<Replica_root>\DO_NOT_REMOVE_NtFrs_PreInstall_Directory. The Preinstall directory is always open exclusively when FRS is running. The following tasks for managing domain controllers are described in this objective: Preparing for Active Directory Installation Installing a Domain Controller in an Existing Domain Adding Domain Controllers in Remote Sites

Installing a Domain Controller in an Existing Domain Using Restored Backup Media Performing an Unattended Installation of Active Directory Verifying Active Directory Installation Renaming a Domain Controller Decommissioning a Domain Controller Forcing the Removal of a Domain Controller

Preparing for Active Directory Installation


Properly preparing for the installation of Active Directory decreases the chances of problems occurring during the installation process and helps you quickly complete the operation. There are a number of requirements for installing Active Directory on a new domain controller in an existing domain. This task addresses general requirements with respect to

Domain Name System (DNS) configuration, placement of the domain controller in a site, and connectivity for the Active Directory Installation Wizard. After you have gathered all the information that you need to run the Active Directory Installation Wizard and you have performed the tests to verify that all the necessary domain controllers are available, you are ready to install Active Directory on your server and create an additional domain controller in the domain. Preparation includes installing and configuring DNS and gathering information that you need for the installation.

Configuring DNS
The DNS client is always present on a server running Windows Server 2003. A DNS server must be present in the forest that stores DNS data for the server. You should properly configure both the DNS client and the DNS server to ensure that name resolution and related dependencies will function as expected during the installation of Active Directory. Ensure that any required configuration, forwarders, or zones are present and accessible prior to installation. For more information about DNS configuration best practices, see Designing the Active Directory Logical Structure on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=25466).

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 controllers 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. A site is allocated according to the following rules: 1. If you specify a site in the Unattended text file that is used to create the new domain controller, the domain controller will be placed directly into that site when it is built.

2. If no site is specified in the Unattended text file when the new domain controller is built, then by default the domain controller will be placed in a site based on its IP address. 3. If you specify a replica partner in the Unattended text file but do not specify a site, the new domain controller should be placed in the replica partner's site. 4. If the replica partner or site is not specified, then the allocation of the site is random. It will depend on the replica partner selected for initial replication.

Domain Connectivity
During the installation process, the Active Directory Installation Wizard needs to communicate with other domain controllers 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 communicates with the domain naming master for domain installs only, so that the new domain controller can be added to the domain. The wizard also needs to contact the relative ID (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. Task requirements During the installation process, the wizard needs to communicate with other domain controllers 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 allow administrative access to the directory. Before you begin your installation, the following conditions must exist in your environment: Your Active Directory forest root domain must already exist.

If you are installing a new domain controller in a child domain, there should be at least two properly functioning domain controllers in the forest root domain. DNS must be functioning properly. In this guide, it is assumed that you are using Active Directoryintegrated DNS zones. You must have configured at least one domain controller as a DNS server. Creating or removing a domain or forest is beyond the scope of this guide. The following information and tools are necessary to complete this task:

The Active Directory Installation Wizard asks for the following specific configuration information before it begins installing Active Directory: A domain administrators user name and password A location to store the directory database and log files A location to store the shared system volume files (SYSVOL) The password to use for Directory Services Restore Mode

The fully qualified DNS name of the domain to which the new domain controller will be added My Network Places Adsiedit.msc Netdiag.exe Active Directory Sites and Services Dcdiag.exe

To complete this task, perform the following procedures: 1. Install the DNS Server service 2. Verify DNS registration and functionality 3. Verify that an IP address maps to a subnet and determine the site association 4. Verify communication with other domain controllers 5. Verify the availability of the operations masters Caution If any verification test fails, do not continue until you determine what went wrong and fix the problems. If these tests fail, the installation is also likely to fail.

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 perform 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. Administrative Credentials

To perform this procedure, you must be a member of either the Domain Admins group or the Enterprise Admins group. To install the DNS server service 1. Ensure that the computer is using a static IP address by right-clicking My Network Places and then clicking Properties. 2. In the Network 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. 3. In the Local Area Connection Properties dialog box, click once on Internet Protocol (TCP/IP) to highlight it (be sure that you do not clear the check box in front of it), and then click Properties. 4. 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 appear. Click OK to close the dialog box. Click OK again to return to your desktop. 5. In Control Panel, click Add or Remove Programs. Click Add/Remove Windows Components. 6. Scroll down to Networking Services. Highlight it and click Details. 7. In the Networking Services dialog box, select the check box in front of Domain Name System (DNS). Click OK. 8. Click Next. Provide the location of the installation files, if necessary. After the installation is complete, click Finish to end the wizard, and then click Close to exit Add or Remove Programs.

Verify DNS registration and functionality


This procedure verifies that DNS is functioning so that other domain controllers can be located. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory.

To verify DNS registration and functionality 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:dns Note For a more detailed response from this command, add /v to the end of the command. 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 with 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 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To verify that an IP address maps to a subnet and determine the site association 1. Log on locally or open a Terminal Services connection to the server for which

you want to check the IP address. 2. On the desktop, right-click My Network Places, and then click Properties. 3. In the Network Connections dialog box, right-click Local Area Connection, and then click Properties. 4. Double-click Internet Protocol (TCP/IP). 5. Use the values in IP address and Subnet mask to calculate the subnet address and then click OK. 6. Click OK again and close the Network Connections dialog box. 7. Open Active Directory Sites and Services. 8. Expand the Sites container, and then click the Subnets container. 9. In the Name column in the details pane, find the Subnet object that matches the subnet address. 10. 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 communication with other domain controllers


This procedure verifies that domain controllers can be located. Administrative Credentials To perform this procedure, you must be a member of the Domain users group in Active Directory. To verify communication with other domain controllers 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:dsgetdc

Note For a more detailed response from this command, add /v to the end of the command. 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 the availability of the operations masters


This procedure verifies that the operations masters can be located and that they are online and responding. Administrative Credentials To perform this procedure, you must be a member of the Domain users group in Active Directory. Note You can use these tests prior to installing Active Directory as well as afterward. 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. 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 test. 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 by adding /v to the end of the command to see the detailed response. To verify the availability of the operations masters 1. Open a Command Prompt. 2. Type the following command to ensure that the operations masters can be located and then press ENTER:

dcdiag /s: domaincontroller /test:knowsofroleholders /verbose 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 the 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. Press ENTER. 3. Type the following command to ensure that the operations masters are functioning properly and are available on the network: 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. Press ENTER. 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.

Installing a Domain Controller in an Existing Domain


This task covers the installation of Active Directory onto a Windows Server 2003 system that will become a domain controller in an existing Active Directory domain. To ensure successful installation of a new domain controller, you should verify that all critical services that Active Directory depends on are configured following Microsoft best practices. For more information about best practices for planning, testing, and deploying Active Directory, see Designing and Deploying Directory and Security Services on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=27638). Task Requirements The following tool is required to perform the procedure for this task: Dcpromo.exe To complete this task, perform the following procedure:

Install Active Directory

You can also install Active Directory from installation media or by performing an unattended installation. For information about completing each of these tasks, see the following: Installing a Domain Controller in an Existing Domain Using Restored Backup Media Performing an Unattended Installation of Active Directory

Install Active Directory


Use the Active Directory Installation Wizard to install Active Directory on a member server in your domain to create an additional domain controller in an existing domain. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To install Active Directory 1. Click Start, click Run, type dcpromo and then press ENTER. 2. The Active Directory Installation Wizard appears. At the Welcome screen, click Next. 3. For Domain Controller Type, select Additional domain controller for an existing domain. Click Next. 4. 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. 5. Enter the name of the domain that you want the new domain controller to host. Click Next. 6. For 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. 7. For Shared System Volume, enter the path where you want to locate the system volume (SYSVOL). Click Next. 8. 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. 9. 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. 10. 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. Verify that this information is correct. Click Finish to close the wizard. 11. Click Restart to restart the domain controller. 12. 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, some services may be 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.

Installing a Domain Controller in an Existing Domain Using Restored Backup Media


When you install Active Directory from restored backup media, you can reduce the replication traffic that is initiated during the installation of an additional domain controller in an Active Directory domain. Reducing the replication traffic reduces the time necessary to install the additional domain controller. The procedures in this task are particularly useful for installing domain controllers in remote sites. By using these procedures, you can avoid having to either replicate the entire Active Directory replica over a wide area network (WAN) link or disconnect an existing domain controller while it is being shipped to the remote site. If you are installing additional domain controllers in remote sites and you want to minimize the Active Directory and SYSVOL replication that is required during the installation from backup media, use the information in this topic in conjunction with the information in Adding Domain Controllers in Remote Sites. When the domain controller that you are installing will be a Domain Name System (DNS) server and you are using Active Directoryintegrated DNS zones, the DomainDNSZones and ForestDNSZones application directory partitions are not included in the restored backup media by default. If you want to include application directory partitions in the restored backup media that is used to install Active Directory, additional procedures are

required to complete the installation task. Follow the instructions for including application directory partitions in the installation media. Task requirements To begin the task to install a domain controller from restored backup media without application directory partitions, ensure that the following requirements are met: A Windows Server 2003based domain controller must be running in each domain where you will be performing installations from backup media. The restored system state backup that is used to create additional domain controllers must be taken from a domain controller in the same domain as the new additional domain controller. The server that is being installed as a domain controller must be running Windows Server 2003, and the version must be the same as the domain controller from which the backup was taken. For example, you cannot use backup media from a domain controller running Windows Server 2003 to create a domain controller running Windows Server 2003 with Service Pack 1 (SP1). The reverse is also true. The restored system state backup that is used to create additional domain controllers must be taken on a domain controller that matches the processor type of the new domain controller. System state backups that are taken on a domain controller that has a 32-bit processor cannot be used to install a domain controller that has a 64bit processor. The reverse is also true. During Active Directory installation, Dcpromo checks that the value of the tombstone lifetime in the restored system state backup matches the value on an existing domain controller. If you plan to change the value of the tombstone lifetime, change this value before you create the backup. If the domain controller that you are creating is to be a global catalog server, the system state backup that you restore must be taken from an existing global catalog server in the domain. On servers that are running Windows Server 2003 with SP1, you can use restored backup media to install a domain controller that is a DNS server (stores the DomainDNSZones and ForestDNSZones application directory partitions) or that stores other application directory partitions. In addition to the previous requirements, to begin the task to install a domain controller from restored backup media that includes application directory partitions, ensure that the following requirements are met: The forest functional level has been raised to Windows Server 2003.

The domain controller on which you created the system state backup is running Windows Server 2003 with SP1.

The domain controller on which you created the system state backup contains the application directory partitions that you want to include. The server computer that you are installing is running Windows Server 2003 with SP1. You have created an answer file that contains the distinguished names (or * for all names) of the application directory partitions that you want to include. The following tools are required to perform the procedures for this task: Ntbackup.exe Dcpromo.exe

Ref.chm or Unattend.txt file, or both, for installations that include application directory partitions. To complete this task, perform the procedures for the following methods: 1. Back up system state Back up the system state of an existing domain controller according to the requirements described above. 2. As an option, before you restore the backup, copy the .bkf file to a CD, DVD, or other removable media from which you will subsequently restore the backup to an alternate location on the local hard drive of the server on which Active Directory is being installed. You can use this media to restore the same backup to any number of servers that will be installed as domain controllers. With this method, you restore the backup for each domain controller that you install. Compare this method to method 3.2, in which you restore the backup only once and copy the restored files to the removable media. 3. Restore system state to an alternate location Select the location for the system state backup that you will use to install a new domain controller. Use one of the following locations for restoring the system state backup: Restore the .bkf file to a volume on the server that will be installed as a domain controller. We recommend restoring to a folder named \NTDSRESTORE on the volume that will host the Ntds.dit file when Dcpromo is run, if space permits. Otherwise, restore to a folder named \NTDSRESTORE on a volume that has sufficient free space. For additional criteria regarding the volume on which you restore the backup, see Adding Domain Controllers in Remote Sites. Restore the .bkf file to the local hard drive of any computer, and then burn the expanded restore tree to a CD, DVD, or other removable storage media. Install Active Directory directly from this media. You can use this media to directly install

any number of domain controllers. With this method, you restore the backup only once. 4. Install Active Directory from media. Install the domain controller from the system state backup that you restored in step 3 by using one of the following methods: Install Active Directory from restored backup media to create a new domain controller that does not include application directory partitions. Include application directory partitions in an Active Directory installation from backup media to create a new domain controller that contains application directory partitions. (See the special requirements described earlier in this section.) This method uses an answer file to specify the application directory partitions to include in the Active Directory installation. To use this method, you must first Create an answer file for domain controller installation. You can also include instructions to install the DNS Server service in the answer file.

See Also
Adding Domain Controllers in Remote Sites Create an answer file for domain controller installation

Back up system state


Ntbackup.exe provides simple and advanced options for backing up Active Directory components. When you back up system state, you can choose to include or exclude system-protected boot files. System-protected boot files are not used for installations from restored backup media. When the backup file that you create is to be used for additional domain controller installations, you can clear the advanced option to back up systemprotected files. Clearing this option decreases the size of the .bkf file, as well as the time required to back up, restore, and copy the system state files. Use these procedures to back up the system state only. These procedures do not back up the system disk or any other data on the domain controller except for the system-protected files. Use the first procedure, "To back up system state including system-protected files," for routine system state backup. Use the second procedure, "To back up system state excluding system-protected files," if you want to create a smaller backup that is effective for installing domain controllers from restored backup media.

Note To back up system state, you must log on locally to the domain controller, or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform the following two procedures, you must be a member of the Domain Admins group or a member of the Backup Operators group. To back up system state including system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. This procedure provides steps for backing up in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard. 2. On the Welcome to the Backup or Restore Wizard page, click Next. 3. Select Back up files and settings, and then click Next. 4. Select Let me choose what to back up, and then click Next. 5. In the Items to Back Up window, double-click My Computer. 6. In the expanded list below My Computer, check System State, and then click Next. 7. Select a location to store the backup: If you are backing up to a file, type the path and file name for the backup (.bkf) file (or click Browse to find a folder or file). If you are backing up to a tape unit, choose the tape that you want to use. Note You should not store the backup on the local hard drive. Instead, store it in a location, such as a tape drive, away from the computer that you are backing up. 8. Type a name for this backup according to the recommendations in Backing Up Active Directory Components, and then click Next. 9. On the last page of the wizard, click Advanced. 10. Do not change the default options for Type of Backup. Normal should be

selected, and the check box for Backup migrated remote storage data should remain cleared. Click Next. 11. Select Verify data after backup, and then click Next. 12. In the Backup Options dialog box, select a backup option, and then click Next. 13. If you are replacing the existing backups, select the option to allow only the owner and administrator access to the backup data and to any backups that are appended to this medium, and then click Next. 14. In the When to back up box, select the appropriate option for your needs, and then click Next. 15. If you are satisfied with all of the options that are selected, click Finish to perform the backup operation according to your selected schedule. Note The system state can also be backed up by using Ntbackup from a command line with appropriate parameters. For more information, at a command prompt type ntbackup /?. The following procedure produces a smaller .bkf file that does not include system boot files. By using this procedure, you can reduce the time that is required to perform the backup and subsequent restore, as well as the amount of disk space that is required. This method is recommended when the restored backup is to be used for installing additional domain controllers. To back up system state excluding system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. 2. On the Welcome to the Backup or Restore Wizard page, click Advanced Mode, and then click the Backup tab. 3. In the console tree, select the System State check box. 4. In Backup media or file name, type a name for this backup according to the recommendations in Backing Up Active Directory Components. 5. Click Start Backup, and then click Advanced. 6. Clear the Automatically back up System Protected Files with the System State check box, and then click OK. 7. Click Start Backup.

See Also
Enable Remote Desktop Create a Remote Desktop Connection

Restore system state to an alternate location


Perform this procedure to create media for installing a domain controller from restored backup media or to allow an authoritative restore of SYSVOL. After the domain controller installation is complete, delete the files in the alternate location. You can restore the system state backup to an alternate location on the domain controller from which the backup was made, a location on another computer, or a location on the computer that you want to install as a domain controller. Administrative credentials To perform this procedure, you must be a member of the Backup Operators group, as follows: Restore system state on a member or workgroup server: Backup Operators group on the local computer Restore system state on a domain controller: Backup Operators group in the domain To restore system state to an alternate location 1. Log on to the server that has the alternate location to which you are restoring system state backup files. 2. Click Start, click Run, type ntbackup, and then click OK. 3. On the Welcome to the Backup or Restore Wizard page, click Next. 4. Click Restore Files and settings, and then click Next. 5. On the What to Restore page, click Browse, and then, in the Open Backup File dialog box, click Browse again. 6. Navigate to the .bkf file that you want to restore to an alternate location. The .bkf file can be located in a folder on the current computer, in a shared folder on the backup computer or other network computer, or on an external drive that

contains removable media. 7. In the Select file for catalog dialog box, click the .bkf file that you want to restore, and then click Open. 8. In the Open Backup File dialog box, click OK. 9. In Items to restore, double-click File, and then double-click the .bkf file that you want to restore. 10. Below the .bkf file that you want to restore, select the System State check box, and then click Next. (You do not need to restore the system disk to an alternate location.) 11. On the Completing the Backup or Restore Wizard page, click Advanced. 12. In the Restore Files to drop-down list, click Alternate Location. 13. In Alternate Location, type the path (or browse) to the local folder to which you are restoring the backup, and then click Next. We recommend restoring to a folder named NTDSRESTORE, if space permits, on the volume that will host the Ntds.dit file when Dcpromo is run. Otherwise, restore to a folder named \NTDSRESTORE on another volume that has sufficient free space. 14. On the How to Restore page, accept the default selection Leave existing files (Recommended), and then click Next. 15. On the Advanced Restore Options page, accept the default selections Restore security settings and Preserve existing volume mount points, and then click Next. 16. On the Completing the Backup or Restore Wizard page, click Finish.

Install Active Directory from restored backup media


Use this procedure to install Active Directory from backup media to create an additional domain controller in an existing domain. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain into which you are installing the additional domain controller.

To install Active Directory from restored backup media 1. Click Start, click Run, type dcpromo /adv, and then press ENTER. 2. In the Active Directory Installation Wizard, select Additional domain controller for existing domain. 3. Select From these restored backup files, and point to the same location where you restored the system state data. 4. If the domain controller whose system state backup you are using is a global catalog server, the Active Directory Installation Wizard asks you whether you want this server to also be a global catalog server. 5. Give appropriate credentials for the operation. 6. Enter the domain of the new domain controller. This domain must be the domain of the domain controller whose system state backup you are using. 7. Complete the remaining pages of the Active Directory Installation Wizard. Dcpromo.exe will install Active Directory using the data present in the restored files, which eliminates the need to replicate every object from a partner domain controller. However, objects that were modified, added, or deleted since the backup was taken must be replicated. If the backup was recent, the amount of replication required will be considerably less than that required for a regular Active Directory installation. After the installation operation completes successfully and the computer is restarted, the folder and subfolders that contain the restored system state can be removed from the local disk.

See Also
Restore system state to an alternate location Include application directory partitions in an Active Directory installation from backup media

Include application directory partitions in an Active Directory installation from backup media
You can use this procedure to install Active Directory from restored backup media that includes application directory partitions to create an additional domain controller in an existing domain. In this procedure, you edit a domain controller installation answer file to provide instructions for including application directory partitions in the installation. You must have already created the answer file according to the directions in Create an answer file for domain controller installation. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain into which you are installing the additional domain controller. To include application directory partitions in an Active Directory installation from backup media 1. Open the answer file that you created to install the domain controller. 2. To include application directory partitions that are contained in the system state backup, add the following entry to the end of the answer file: ApplicationPartitionsToReplicate= 3. Provide a value for ApplicationPartitionsToReplicate as follows: If you want to include all application directory partitions, use the value *.

If you want to include specific application directory partitions, type the distinguished name of each directory partition. Separate each distinguished name with a space, and enclose the entire list in quotation marks, as shown in the following example: ApplicationPartitionsToReplicate="dc=app1,dc=contoso,dc=com dc=app2,dc=contoso,dc=com" 4. In the entry ReplicationSourcePath=, type the path to the folder that contains the restored system state backup files on the installation computer. 5. If you do not want Dcpromo to prompt the user for passwords, type the password in the Password= entry for the account that you will use to install the domain controller, type the password in the SafeModeAdminPassword= entry that you will use to provide access to Directory Services Restore Mode, and then

save the answer file. Note Passwords are automatically deleted from the answer file when Dcpromo runs. 6. Open a command prompt, and then change directories to the location of the answer file. 7. At the command prompt, type the following command, and then press ENTER: dcpromo /adv /answer:"Drive:\PathToAnswerFile\AnswerFileName" Active Directory installation occurs automatically. If you left passwords blank in the answer file, Dcpromo prompts you for your administrative password and for the Directory Services Restore Mode password. If you specified "no" for the RebootOnSuccess= entry in the answer file, Dcpromo prompts you to restart the server after installation.

Adding Domain Controllers in Remote Sites


You can create an additional domain controller in a domain by installing Active Directory on a server computer. When the additional domain controller is being placed in a remote site, you can install Active Directory on the server either before or after shipping it to the remote site, as follows: Ship the computer as a workgroup computer, and install Active Directory in the remote site. Enable Remote Desktop on the computer before you ship it so that you can perform the installation remotely. In the remote site, you can either: Install Active Directory from restored backup media that has been shipped to the site on removable media or that has been restored to a location on the server itself before shipping. Install Active Directory over the network.

Install Active Directory on the server in a hub or staging site, and ship the installed domain controller to the remote site.

Both methods have advantages and disadvantages, and both methods require care to ensure the secure transfer of Active Directory data, whether it is installed or in the form of backup files that are stored on the server or on removable media. For information about the advantages and disadvantages of shipping a server to a remote site before or after installing Active Directory, see Known Issues for Adding Domain Controllers in Remote Sites. For information about how best to manage adding domain controllers to remote sites for the method you are using, see Best Practices for Adding Domain Controllers in Remote Sites. By following the guidelines in this guide, you can decide the best method for your environment of adding domain controllers in remote sites. By following the instructions in this guide, you can safely and securely install domain controllers in remote sites, either locally or remotely. The following tasks for adding domain controllers in remote sites are described in this objective: Preparing a Server Computer for Shipping and Installation from Backup Media

Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection Reconnecting a Domain Controller After a Long-Term Disconnection

Known Issues for Adding Domain Controllers in Remote Sites


You can use the following two methods to add domain controllers in remote sites: Ship the member computer to the remote site, and then install Active Directory by using the dcpromo /adv option, which uses restored system state backup media as the source for the Active Directory installation in the remote site. Install Active Directory in the hub site by using the normal Dcpromo method, and then ship the installed domain controller to the remote site. You can use the information in this section to determine the method for adding domain controllers in remote sites that is best for your environment. SYSVOL replication issues potentially affect both methods, and each method has advantages and disadvantages that are discussed in this section.

Important Do not attempt to perform actions based only on the recommendations that are discussed in this topic. Step-by-step guidance is provided in the task-based topics for all actions that are recommended in this topic. Follow the See Also links to the related task-based topics.

SYSVOL Replication
SYSVOL is a shared folder that stores files that must be available and synchronized among all domain controllers in a domain. SYSVOL contains the NETLOGON share, Group Policy settings, and File Replication service (FRS) staging directories and files. The SYSVOL share is required for Active Directory to function properly. The primary focus for both methods of installing additional domain controllers in remote sites is to avoid the replication of Active Directory over a wide area network (WAN) between the remote site and the hub site. Each method accomplishes this goal. However, depending on the size of your SYSVOL, you might also be concerned about replication of SYSVOL files over the network. Unless you follow specific instructions, the SYSVOL tree might be created on the new domain controller through replication of the entire tree from an existing domain controller in the domain. Regardless of which method you use to add domain controllers to remote sites, you might want to take additional steps to manage SYSVOL creation on the new domain controller to avoid replicating the full SYSVOL from another domain controller in the domain. When you install a domain controller from backup media, preliminary steps are required to ensure that SYSVOL is created from the local copy of the restored backup media. Similarly, preliminary steps are required to avoid full SYSVOL synchronization when you ship an installed domain controller and restart it in the remote site. These requirements are discussed for each method respectively in the following topics: Preparing a Server Computer for Shipping and Installation from Backup Media

Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection

Using Backup Media to Install Active Directory in a Remote Site


The ability to use restored backup media to install domain controllers is a new feature in Windows Server 2003. The method for using backup media to install domain controllers includes the following general steps:

1. Back up system state on a domain controller in the domain in which you are adding the new domain controller. If you want the additional domain controller to be a global catalog server, back up a global catalog server. If you want the additional domain controller to be a Domain Name System (DNS) server, back up a DNS server. 2. Restore the backup to an alternate location. You can restore the backup directly to the computer that you want to install as a domain controller, or you can transfer it to removable media. 3. Run Dcpromo with the /adv option and indicate the restored backup as the source for the Active Directory installation. This method of installing domain controllers in remote sites has several advantages. One of the primary advantages of this method is that it substantially reduces the network bandwidth requirement compared to network-based installations. This method also has a few issues that mostly affect deployments that have a large number of remote sites. If you deploy more than 100 remote sites, additional considerations might be necessary. For information about large branch office deployments, see the Windows Server 2003 Active Directory Branch Office Guide on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42506).

Advantages of Using Backup Media to Install Active Directory in a Remote Site


The following advantages are associated with using backup media to install a domain controller in a remote site: You can install many domain controllers from a single source of removable backup media. Although you can restore backup media directly to an alternate location on the server computer that you are going to install as a domain controller, you can also use that media as the source for any number of domain controllers by either copying or restoring the system state backup to removable media. For more information about the effects of copying as opposed to restoring a system state backup to removable media, see Preparing a Server Computer for Shipping and Installation from Backup Media. You do not have to disconnect the domain controller from the replication topology. Therefore, you can avoid the disadvantages that are associated with a domain controller that does not replicate. For information about the problems that are associated with domain controller disconnection, see Issues with Installing Domain Controllers Before Shipping Them to the Remote Site. You avoid replicating the entire Active Directory over a WAN link, particularly a link that requires a dial-up connection.

If you enable Remote Desktop on the server before you ship it, you do not have to employ an administrator with Domain Admins credentials in the remote site.

Issues with Using Backup Media to Install Active Directory in Remote Sites
The following issues are associated with using backup media to install a domain controller in a remote site: Domain Admins credentials and remote installation. An administrator must have Domain Admins credentials to install Active Directory. Assuming that you do not employ a service administrator with this level of administrative credentials in each branch site, a domain administrator in the hub site must be able to connect remotely to the server to perform the installation. Therefore, you must be sure to enable Remote Desktop on the server before you ship it to the remote site. Time to restore the system state backup. The installation media is prepared by restoring a system state backup to an alternate location. Therefore, preparing the media requires taking the backup itself and restoring the backup. These tasks add time to the installation of a single domain controller. However, if you take advantage of the ability to transfer the restored backup files to removable media, you perform the preliminary backup and restore processes only once to install any number of domain controllers. In addition, you can follow instructions to prepare a smaller backup file to further decrease the time that is required for restoring and copying backup media. The volume on which you restore the backup on the target server also affects the speed of the installation. Moving the Ntds.dit file is faster than copying it. If you restore the media to the same location that will be used to host the Active Directory database, the Ntds.dit file will be moved (as opposed to being copied) into the new location, eliminating the additional time required to copy the file. For more information about the criteria that affect how long installation from backup media takes, see Preparing a Server Computer for Shipping and Installation from Backup Media. Backup source for application directory partitions. When DNS zone data is stored in application directory partitions, the replication impact can be significant if application directory partitions must be replicated over the corporate network. System state data that you restore from backup to an alternate location does not include application directory partitions if the backup is performed on servers running Windows Server 2003 with no service pack installed. Including application directory partitions in the backup media has the following requirements:

The domain controller that you back up and the computer that you intend to install as a domain controller must both be running Windows Server 2003 with Service Pack 1 (SP1). The forest functional level must be set to Windows Server 2003 because linked-value replication is required to ensure that cross-references are correctly updated for the application directory partition replica set. You must use an answer file to install Active Directory because the Dcpromo user interface (UI) does not provide an option for specifying application directory partitions. Use the answer file to provide the distinguished names of the application directory partitions that you want to include in the installation. For more information about how to include application directory partitions and create a DNS server, see Preparing a Server Computer for Shipping and Installation from Backup Media. Bridgehead server load balancing. If backup media are sent to many sites and if enough domain controllers are promoted at the same time, you might experience performance issues with the bridgehead servers that are the source for Active Directory and FRS replication. Note These issues are of concern only in situations in which hundreds of domain controllers might be promoted at the same time and their need for bridgehead server resources is very high. If you are deploying hundreds of domain controllers in branch sites, see the Windows Server 2003 Active Directory Branch Office Guide on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=42506). Active Directory intersite replication. You cannot load-balance intersite connections to and from the hub site until the domain controller is installed. If a large number of domain controllers are being installed in remote sites (more than 100), manual rebalancing of connections might be required after the domain controllers are installed. For information about how to use the Active Directory Load Balancing (ADLB) tool to rebalance connections, see the Windows Server 2003 Active Directory Branch Office Guide on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42506). FRS replication. Because FRS on the source computer uses CPU, memory, and disk resources, the FRS recommendation is to perform a staged update on no more than 10 branch office domain controllers at a time per source hub domain controller. If a single domain controller functions as the source for SYSVOL replication to more than 10 destination domain controllers, performance on the

source domain controller can decrease significantly. To balance source domain controllers, you can use an answer file with Dcpromo to specify the source domain controller.

Installing Domain Controllers Before Shipping Them to the Remote Site


When you install a domain controller and then disconnect it from the network for a period of time, you interrupt the normal replication activities of other domain controllers on the network. This naturally creates error conditions that result from various failed operations, such as attempts to replicate with the disconnected domain controller. As long as you are aware of the issues that disconnections cause, you can take steps to ensure smooth disconnection and reconnection.

Advantages of Installing Domain Controllers Before Shipping Them to the Remote Site
The following advantages are associated with installing domain controllers before shipping them to the remote site: Standardization. The process for installing domain controllers can be automated and standardized in the hub or staging site, with the one additional step of packing and shipping the domain controller. If you follow the instructions for safe disconnection and reconnection, restarting the domain controller in the remote site is all that is required. Branch site personnel. The requirement for personnel with Domain Admins credentials is contained within the hub site; that is, intervention by personnel with Domain Admins credentials is not required at the branch site.

Issues with Installing Domain Controllers Before Shipping Them to the Remote Site
The following issues are associated with installing domain controllers and then disconnecting them from the network while they are shipped to the remote site: Disconnection error conditions. After disconnection, online domain controllers in the domain continue to attempt replication with the disconnected domain controller, causing Active Directory and FRS errors to be generated for as long as the domain controller is disconnected. Additional preparation. Additional preparation is required to ensure smooth reconnection:

Preparing for the nonauthoritative restart of SYSVOL.

Ensuring an adequate tombstone lifetime to avoid the possibility of objects remaining on the domain controller that have been permanently deleted from the directory on all other domain controllers. The tombstone lifetime is a forest-wide setting that determines how long an object deletion persists in the directory. Protection of existing accounts and metadata. You must ensure that computer accounts and metadata for the domain controller are not deleted or improperly modified while the domain controller is disconnected. Risk of lingering objects. A lingering object is an object that remains on a disconnected domain controller after the object has been permanently deleted from Active Directory on all connected domain controllers. Deletion updates are replicated as tombstone objects. These objects have a limited lifetime in Active Directory, which is defined by the tombstone lifetime. After a tombstone is permanently removed from Active Directory, replication of the deletion it represented is no longer possible. Therefore, if you restart a domain controller on which such an object remains, replication does not recognize that object as a deleted object, and it remains in Active Directory on only the reconnected domain controller and nowhere else. If you plan to disconnect a domain controller for longer than the period of time that a domain controller keeps track of object deletions (the tombstone lifetime), you must take additional steps to ensure directory consistency. For more information about lingering objects and their causes and effects, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042).

Maintaining Directory Consistency When Disconnecting a Domain Controller


Maintaining consistency of Active Directory data involves several related issues. Review the following known issues before disconnecting an installed domain controller: Relationship of tombstone lifetime to Active Directory backup Protection against lingering object replication Availability of operations master roles in the domain and forest Up to dateness of Active Directory replication at the time of disconnection SYSVOL consistency on reconnection

For procedures to ensure that all of these issues are addressed, see the following topics: Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection

Reconnecting a Domain Controller After a Long-Term Disconnection

Tombstone Lifetime and Backup


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 in a Windows Server 2003 forest. This default value is changed in Windows Server 2003 with Service Pack 1 (SP1). The tombstone is retained for 180 days by default in a new forest that is created on a domain controller running Windows Server 2003 with SP1. NTBackup.exe, the Windows Server backup utility, will not restore a system state backup that is older than the tombstone lifetime. The tombstone lifetime value that is in effect when a domain controller is upgraded to Windows Server 2003 SP1 is not changed by the installation of Windows Server 2003 SP1. The existing value is maintained until you change it manually. You can determine the value of the tombstoneLifetime attribute by viewing the properties of CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain in ADSI Edit (adsiedit.msc), which is available in Windows Support Tools. A value in tombstoneLifetime of <Not Set> always indicates that the Windows Server 2003 default value of 60 is in effect. If you create a new forest on a domain controller running Windows Server 2003 with SP1, the default tombstoneLifetime value of 180 is displayed in the UI. When the number of days in the tombstone lifetime has passed, the tombstone is permanently removed. Because a domain controller that is disconnected for a period that is longer than the tombstone lifetime cannot receive deletions that occurred before 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 for a period that is 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. If planned domain controller disconnections are consistently lasting longer than the number of days in the tombstone lifetime, consider extending the tombstone lifetime for the forest prior to disconnecting any domain controllers. For more information about the causes and effects of lingering objects, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042).

Protection Against Lingering Object Replication


Domain controllers that have not performed inbound replication in the previous tombstone lifetime number of days are vulnerable to retaining lingering objects. If a domain controller that has one or more lingering objects is reconnected to the replication topology and a lingering object is subsequently updated on that domain controller, the object might be recreated in Active Directory, depending on how the strict replication consistency registry setting is configured. A lingering object is made known to the replication system only if it is updated on the domain controller that stores it. In this case, the source domain controller attempts replication of an update to an object that the destination does not store. On destination domain controllers running Windows 2000 Server with Service Pack 3 (SP3) or Service Pack 4 (SP4) and Windows Server 2003, the strict replication consistency registry entry (type REG_DWORD) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters) determines whether replication is allowed to proceed if the domain controller receives a request for an update to an object that it does not have. The value in the strict replication consistency registry entry determines whether replication proceeds or is stopped, as follows: 1 (enabled): Inbound replication of the specified directory partition from the source is stopped on the destination. Replication of the directory partition is halted on both the source and destination domain controllers. 0 (disabled): The destination requests the full object from the source domain controller and the destination domain controller reanimates a full copy of an object it has previously deleted and permanently removed through garbage collection. For more information about how to manage the strict replication consistency setting, including its effects and its default values, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042).

Up to Dateness of Active Directory Replication


Ensure that a domain controller is updated before you disconnect it. Immediately before you disconnect 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 before you disconnect the domain controller. 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.

SYSVOL Consistency
SYSVOL replication cannot be synchronized manually. For this reason, ensuring that SYSVOL is updated before you disconnect 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 nonauthoritative restart of SYSVOL before you disconnect the domain controller. When the domain controller restarts, nonauthoritative restart of SYSVOL occurs automatically.

See Also
Preparing a Server Computer for Shipping and Installation from Backup Media Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection Reconnecting a Domain Controller After a Long-Term Disconnection

Best Practices for Adding Domain Controllers in Remote Sites


By reviewing the information in Known Issues for Adding Domain Controllers in Remote Sites, you can determine the best method to use for installing domain controllers in your remote sites. You can use this topic to learn about the best practices for the method that you decide to use. Important Do not attempt to perform actions based only on the recommendations that are discussed in this topic. Step-by-step guidance is provided in the task-based topics for all actions that are recommended in this topic. Follow the See Also links to the related task-based topics.

Using Backup Media to Install Active Directory in the Remote Site


The primary purpose of using restored backup media to install a domain controller is to provide a local source for the domain, configuration, and schema directory partitions and, optionally, global catalog partial, read-only directory partitions and Domain Name System (DNS) application directory partitions. The local source is the restored system state

backup files that reside on the server that you are installing. Updates to object attributes that occur since the system state backup was made will replicate over the network from an existing domain controller in the domain or forest. Although SYSVOL is part of the system state backup, under some conditions SYSVOL is not sourced from the backup media. Configuring SYSVOL to be sourced from local backup media is more challenging and might not prove worthwhile. For more information about the conditions that determine the need for SYSVOL replication, see Known Issues for Adding Domain Controllers in Remote Sites. To use restored backup files for installation of one or more additional domain controllers in a domain, you can either: Copy ("burn") either the unrestored .bkf file or the restored backup files onto removable media, such as a portable disk drive, CD, or DVD, which can be shipped with the workgroup computer when it leaves the staging site or shipped separately. Restore system state backup to the local hard drive of the workgroup computer before it leaves the staging site. For information about the advantages and disadvantages of these methods, see Preparing a Server Computer for Shipping and Installation from Backup Media. The Dcpromo /adv option in Windows Server 2003 to install a domain controller from backup media eliminates the Windows 2000 Server requirement to either promote the domain controller before shipping it to the remote site or promote the domain controller in the remote site by replicating the entire directory over a wide area network (WAN) connection when another domain controller for the domain is not present in the site. The following best practices are recommended to optimize data security and consistency when you add domain controllers in remote sites: Upgrade to Windows Server 2003 with Service Pack 1 (SP1). If you use Active Directory-integrated DNS or if you want other application directory partitions to be included in the domain controller replica, upgrade the server computer to Windows Server 2003 with SP1 before Active Directory installation. When you use restored backup media to install a computer running Windows Server 2003 with no service pack installed, the replica installation does not include application directory partitions. In the case of DNS application directory partitions, the impact of replicating these directory partitions over the WAN might be significant. When you use restored backup media to install a computer running Windows Server 2003 with SP1, you can use an answer file to include application directory partitions in the replica that you install. Back up the type of domain controller that you want to add. You must back up the type of domain controller that you want to add. If you want to add a global catalog

server in the remote site, back up a global catalog server in the domain. If you want to add a DNS server, back up a DNS server in the domain. Take the same security precautions for shipment of removable backup media or a server computer that contains a restored backup as you would take for shipping an installed domain controller. For information about securing domain controllers, see Best Practice Guide for Securing Windows Server Active Directory Installations on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=28521). Minimize the time between the backup and installation. Minimizing this delay reduces the number of updates that will be required to replicate after installation. Install the operating system before shipping the server to the remote site. Installing the operating system requires expertise that might not be available at branch sites. Ideally, installation routines are available in the staging site to automate the operating system installation process and ensure uniformity for all domain controllers (partition sizes, drive letter assignments, and so on). As part of the operating system installation, apply a standardized set of hotfixes plus any available service packs to ensure service consistency throughout the forest. Ship the server as a member of a workgroup rather than a member server in a domain. If the server is joined to a domain and then stolen during shipment, information about domain names, DNS suffixes, and number of domains in the forest can aid attackers in attempts to compromise or steal directory data. Ship computers with properly configured Internet Protocol (IP), subnet mask, and default gateway addresses. Remember to reconfigure the server with TCP/IP settings that are appropriate to the target site, not the staging site. Specifically, the domain controller must not point to itself for DNS. Enable Remote Desktop on the server computer before shipping. This best practice assumes that you need to be able to install and manage Active Directory remotely rather than employing an administrator with Domain Admins credentials in each remote site.

Installing Domain Controllers Prior to Shipping to the Remote Site


When you install Active Directory in the hub or staging site, disconnect the installed domain controller, and then ship the computer to the remote site, you are disconnecting a viable domain controller from the replication topology. The most significant risk from disconnection is that the domain controller will remain offline long enough to exceed the tombstone lifetime and thereby become capable of retaining objects that have been permanently

deleted from the directory on all other domain controllers in the domain. Such objects, called lingering objects, cause directory inconsistency and, under certain conditions, can be reintroduced into the directory. For information about the causes and effects of lingering objects and how to avoid them, see Known Issues for Adding Domain Controllers in Remote Sites. The following best practices reduce the possibility of Active Directory consistency problems due to lingering objects remaining on domain controllers that are disconnected for long periods of time. Take the following precautions to avoid directory consistency problems when you disconnect an existing domain controller and to ensure that if inadvertent long disconnections occur, lingering objects cannot be replicated. Upgrade all Windows 2000 Server domain controllers to Windows Server 2003. This process requires upgrading the forest schema by using the adprep /forestprep command. Thereafter, you can begin upgrading domain controllers to Windows Server 2003. The Windows Server 2003 schema update adds 25 indexed attributes to the schema directory partition. An update of this size can cause replication delays in a large database. For this reason, domain controllers that are running Windows 2000 Server must be running at a minimum Windows 2000 Service Pack 2 (SP2) plus all additional Windows updates. However, it is highly recommended that you install Windows 2000 Service Pack 3 (SP3) on all domain controllers before preparing your infrastructure for upgrade to the Windows Server 2003 operating system. For information about upgrading to Windows Server 2003, see "Upgrading from Windows 2000 Domains to Windows Server 2003 Domains" in the Windows Server 2003 Deployment Guide on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=46082). Enable strict replication consistency on all domain controllers. This registry setting, which stops inbound replication of a directory partition from a source domain controller that is suspected of having a lingering object, should be set for the forest to prevent the reintroduction of a lingering object into the directory. You can use the Repadmin /regkey command, which is available in the version of Windows Support Tools that is included with Windows Server 2003 SP1, to enable this setting on a specific domain controller or on all domain controllers in the forest, which eliminates the need to update the registry manually. Monitor the Knowledge Consistency Checker (KCC) topology and replication to ensure that unintended long disconnections are detected. By monitoring replication, you can detect disconnections that occur as a result of network failures, service failures, or configuration errors. Use the Active Directory Management Pack or other monitoring application to implement a monitoring solution for your Active Directory deployment. Event IDs to monitor include 1311, 1388, 1925, 1988, 2042, 2087, and 2088.

Ship computers with properly configured IP, subnet mask, and default gateway addresses. Remember to reconfigure the server with TCP/IP settings that are appropriate to the target site, not the staging site. Specifically, the domain controller must not point to itself for DNS. Configure the tombstone lifetime appropriately. Ensure that the tombstone lifetime is not lowered below the default. The default tombstone lifetime in a forest that was created on a domain controller running Windows 2000 Server or Windows Server 2003 is 60 days. The default tombstone lifetime in a forest that was created on a server running Windows Server 2003 with SP1 is 180 days. If you must disconnect a domain controller for a period of several weeks or months, before you disconnect the domain controller, do the following: Estimate the anticipated length of disconnection.

Determine the value of the tombstone lifetime for the forest. This value is stored in the tombstoneLifetime attribute of CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ForestRootDomain. Determine the maximum length of time that the domain controller can be safely disconnected. From the tombstone lifetime number of days, subtract a generous estimate of the number of days that are required for end-to-end replication latency. The resulting amount of time is the maximum period for which the domain controller can safely be disconnected. Determine whether to extend the tombstone lifetime for the forest. If you estimate the maximum time of disconnection to be longer than the tombstone lifetime, you must determine whether to extend the tombstone lifetime or perform the procedure to remove lingering objects from the domain controller after it is reconnected. If you extend the tombstone lifetime, you must also make sure that all domain controllers have adequate disk space to store additional tombstones. In addition, make sure that replication of the tombstone lifetime change has reached all potential source domain controllers before you run Dcpromo to install an additional domain controller. Prepare the registry for automatic nonauthoritative restart of SYSVOL when the domain controller restarts. SYSVOL cannot be updated manually before disconnection. By editing a registry setting, you can ensure that SYSVOL is updated as soon as the domain controller is restarted. Ensure that the domain controller replicates successfully with all replication partners. Immediately before you disconnect the domain controller, force replication with its partners. Check that replication has succeeded before you disconnect the domain controller.

Label the domain controller. When you disconnect the domain controller, attach a label to the computer that identifies the date and time of disconnection, the destination, and the IP settings. When you reconnect the domain controller, restore SYSVOL as quickly as possible. The domain controller does not serve as a domain controller until SYSVOL has been updated through replication. If the site has one or more other domain controllers in the same domain, start the domain controller anytime. If the site contains no other domain controller in the same domain, time the restart of the domain controller to coincide with the beginning of intersite replication. Do not allow an outdated Windows 2000 Server domain controller to replicate. If a domain controller running any version of Windows 2000 Server has been disconnected for longer than the maximum safe time of disconnection (the tombstone lifetime minus end-to-end replication latency), do not allow the domain controller to replicate. Instead, force the removal of Active Directory, perform metadata cleanup, and then reinstall Active Directory. As an alternative, you can reinstall the domain controller with Windows Server 2003. For more information about completing these tasks, see Reconnecting a Domain Controller After a Long-Term Disconnection. Note This recommendation applies to additional domain controllers in an existing domain. If the outdated domain controller is the only domain controller in the domain, the recommendation is to reconnect the domain controller and follow the instructions to remove lingering objects in article 314282, "Lingering objects may remain after you bring an out-of-date global catalog server back online," in the Microsoft Knowledge Base on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=37924). To avoid time skew issues, ensure that the system clock is synchronized with the domain source on startup. When you start the domain controller in the remote site, use the following command to set the hardware clock: net time /domain:DomainName /set /y

See Also
Known Issues for Adding Domain Controllers in Remote Sites Preparing a Server Computer for Shipping and Installation from Backup Media Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection Reconnecting a Domain Controller After a Long-Term Disconnection

Managing SYSVOL How the Active Directory Replication Model Works Active Directory Management Pack Technical Reference for MOM 2005

Preparing a Server Computer for Shipping and Installation from Backup Media
The specific guidelines for installing Active Directory from backup media are provided in the topic Installing a Domain Controller in an Existing Domain Using Restored Backup Media. Be sure to read that topic before performing the procedures that are specified in this topic. When you want to ship theserver to a remote site and install Active Directory by restoring from backup media in the remote site, you must make certain choices regarding the method that you use to restore the backup. You must also decide whether to use removable media or ship the backup on the server that will become the additional domain controller. You can use the information in this topic to make these decisions and to prepare the server for shipping. Use the information in Installing a Domain Controller in an Existing Domain Using Restored Backup Media to perform the actual backup, restore, and Active Directory installation procedures. Preparing a computer for installation in a remote site by using restored backup media requires that you perform the following tasks: Begin by backing up system state on a domain controller in the domain into which you are installing the domain controller according to the recommendations and requirements in Installing a Domain Controller in an Existing Domain Using Restored Backup Media. Determine whether to restore the system state backup onto the computer that will be promoted or use removable media to ship the backup files separately from the computer. Determine the volume on which to restore the backup media. If you have a large Ntds.dit file, this decision can affect the amount of time necessary for Active Directory installation. If you have a large SYSVOL, this decision can affect whether full replication of SYSVOL occurs during Active Directory installation. The ability to use the backup media to source SYSVOL depends on various factors. If you want to avoid full replication of SYSVOL, additional preparation is required, as described later in this section.

Before you ship the server, enable Remote Desktop access on the server so that you can install the domain controller and manage it remotely. You can also enable Remote Desktop remotely by using the registry, but this method should be used only as a fallback measure if, through some oversight, Remote Desktop is not enabled prior to shipping. If you are installing a domain controller that is running Windows Server 2003 with Service Pack 1 (SP1) in a forest that has a forest functional level of Windows Server 2003 or Windows Server 2003 interim and you want to include application directory partitions in the installation media, you can do so by creating an answer file that contains the location of the restored backup media and then running an unattended installation of Active Directory.

Restore the Backup to the Promotion Computer or Ship Removable Media


When you back up system state for the purpose of creating restored backup media for domain controller installation, you can use various methods to create the media for shipment and installation. You can: Before you ship the server, restore the backup directly to a volume on the server that you are shipping. When the server arrives at the remote site, it is ready for installation with no further preparation. Copy the .bkf file onto removable media before restoration. Ship the media to the remote site, and then restore the backup from the removable media to an alternate location on each domain controller that you want to install. The advantage of this method is that you retain the potential for SYSVOL to be sourced from the backup media. Restore the backup to any location on any server and then copy the restored backup to removable media, such as a CD, DVD, or portable hard drive. The advantage of using this method is that you restore the backup only once; you can install as many domain controllers as necessary from the same media. The disadvantage is that copying the restored files loses the SYSVOL data that is required for sourcing SYSVOL from the restored backup. For more information about ensuring that SYSVOL is sourced from the restored backup, see "Seeding the SYSVOL tree from restored files during IFM promotion" in article 311078, "How to use the Install from Media feature to promote Windows Server 2003based domain controllers," on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=37924).

Determine the Restore Volume


The volume on which you restore the system state backup has implications for both Active Directory files and SYSVOL files. For faster restore, it is recommended that you restore the backup to the volume that you will designate to host the Ntds.dit file when you run Dcpromo, if space permits. Otherwise, restore the backup to a volume that has sufficient free space. Restoring the backup to the volume that will store Ntds.dit, as opposed to a different volume, affects how files are managed by the system during and after Active Directory installation, as follows: Active Directory files. The volume to which you restore the Ntds.dit and NTDS log files determines how long installation will take and whether you must delete copied files following installation: If you restore the system state to a location on the same volume (drive letter) that will ultimately host the Ntds.dit and NTDS log files, when you designate the path for the Ntds.dit and NTDS log files during installation, the Active Directory Installation Wizard will move the Ntds.dit and NTDS log files from the restored location to their installed location. Moving the files is much faster than copying the files. If you restore the system state to a different volume than the volume that will ultimately host the Ntds.dit and NTDS log files, the Active Directory Installation Wizard will copy the Ntds.dit and NTDS log files to their final location during installation. In the case of a large Ntds.dit file, the copy process can add significantly to the installation time. In this case, you must manually delete the remaining files and folders in the restored folder after a successful installation. As a best practice, we recommend that you always delete the folder that you use to receive the restored backup, regardless of whether files are copied or moved. SYSVOL replication. The volume to which you restore the system state backup also determines whether the File Replication service (FRS) uses the restored files as the source for SYSVOL on the new domain controller or whether FRS replicates a new copy of SYSVOL from a different domain controller in the domain. To source the SYSVOL data from the restored backup, you must restore the system state backup to the same volume as the drive that you specify in the Active Directory Installation Wizard to host the SYSVOL tree. Otherwise, the data will be sourced over the network from a domain controller that is in the same domain as the new domain controller. If you store the SYSVOL shared folder on a different volume from the Active Directory files, consider the effect of copying Active Directory files, as described earlier in this topic, as opposed to the effect of replicating the entire contents of the SYSVOL shared folder. If avoiding replication of the SYSVOL shared folder is a goal of the remote

installation, restore the backup to a location that is on the same volume as the drive that will contain the SYSVOL share. If only one domain controller is installed in the domain (SYSVOL has not replicated at least once between two domain controllers in the domain), the ability to source SYSVOL from the restored backup media requires preliminary configuration of a "helper" domain controller to prepare the SYSVOL before you perform the system state backup. Note It is recommended that you deploy at least two domain controllers in each domain for redundancy and failover. For more information about how to ensure that SYSVOL is sourced from the restored backup, see "Seeding the SYSVOL tree from restored files during IFM promotion" in article 311078, "How to use the Install from Media feature to promote Windows Server 2003 based domain controllers," on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=37924). To assess the effect of replication, as opposed to additional configuration to source SYSVOL from the backup media, test both procedures in a lab environment that mirrors your production environment in terms of wide area network (WAN) speed and replication latency.

Enable Remote Desktop


You can use Remote Desktop to connect to the domain controller and manage it as if you were sitting at the console. Remote Desktop is disabled by default in Windows Server 2003 operating systems. To install Active Directory, you must have Domain Admins credentials in the domain into which you are adding the domain controller. This level of service administration might not be available in the remote site. In any case, you will want to be able to install and manage the domain controller from the hub site.

Create a Domain Controller Installation Answer File


If you want to include application directory partitions in the restored backup media that you use as the source for an Active Directory installation, you must create a domain controller installation answer file and perform an unattended Active Directory installation. Dcpromo uses the answer file for installation instructions, including the location of restored backup media and instructions to use these files as the source for the installation.

If you are installing a domain controller in a remote site that will also be a DNS server, you might want to include application directory partitions in the installation media rather than replicating them. You can include application directory partitions in the installation media if the following conditions apply: The forest has a functional level of Windows Server 2003 or Windows Server 2003 interim. The domain controller that you back up and the server that you are installing are both running Windows Server 2003 with SP1. For creating a DNS server, your forest uses Active Directory-integrated DNS (DNS zone data is stored in application directory partitions on DNS servers in the forest). The domain controller that you back up stores the application directory partitions that you want to include. Instructions for performing this type of installation are included in this task. Task requirements The following tools are necessary to complete this task: Ntbackup.exe System Control Panel Dcpromo.exe

Ref.chm on the Windows Server 2003 installation CD (for unattended installations only) To complete this task, perform the following procedures: 1. Back up system state on a domain controller in the domain into which you are installing the additional domain controller. The following requirements apply for the backup domain controller and the target server: The backup domain controller and target server must be running the same version of Windows Server 2003. For example, if the domain controller that you back up is running Windows Server 2003 with SP1, you cannot use this backup media to install Active Directory on a server that is running Windows Server 2003 with no service pack installed. The backup domain controller and target server must be running on the same hardware platform (32-bit or 64-bit). To install a domain controller that is a global catalog server, you must back up system state on a global catalog server.

To install a domain controller that is a DNS server (that is, a server that stores the DomainDNSZones and ForestDNSZones application directory partitions), you must back up system state on a DNS server that stores these directory partitions. 2. Restore system state to an alternate location. This location can be on the target server or in a different location, from which the backup files can be copied to removable media and then shipped to the remote site separately from the target server. Follow the guidelines described in "Determine the Restore Volume" earlier in this topic. As an alternative, you can copy the unrestored .bkf file to removable media and then ship the media to the remote site, where it can be restored to a location on the target server. When you restore, you must run Ntbackup on the server that has the alternate location. Therefore, if you are restoring to an alternate location that is not on the server on which the .bkf file is stored, before you run Ntbackup, do the following: a. Share the folder that contains the .bkf file. b. Map a connection to it from the computer on which you are running Ntbackup. 3. Enable Remote Desktop on the target server. 4. If you are installing a DNS server or a domain controller that will store any application directory partitions, Create an answer file for domain controller installation. 5. Ship the domain controller and any prepared removable media and answer file to the remote site. Ship these items separately and securely. 6. When the server is running in the remote site, install the domain controller as follows: Create a Remote Desktop Connection to the remote server.

If you are installing a domain controller that does not require application directory partitions to be included in the installation, Install Active Directory from restored backup media. If you are installing a domain controller that will be a DNS server or that requires other application directory partitions to be included in the installation media, perform the procedure to Include application directory partitions in an Active Directory installation from backup media. 7. If the domain controller is to be a DNS server, Install the DNS Server service after Active Directory has been installed.

See Also
Installing a Domain Controller in an Existing Domain Using Restored Backup Media

Back up system state


Ntbackup.exe provides simple and advanced options for backing up Active Directory components. When you back up system state, you can choose to include or exclude system-protected boot files. System-protected boot files are not used for installations from restored backup media. When the backup file that you create is to be used for additional domain controller installations, you can clear the advanced option to back up systemprotected files. Clearing this option decreases the size of the .bkf file, as well as the time required to back up, restore, and copy the system state files. Use these procedures to back up the system state only. These procedures do not back up the system disk or any other data on the domain controller except for the system-protected files. Use the first procedure, "To back up system state including system-protected files," for routine system state backup. Use the second procedure, "To back up system state excluding system-protected files," if you want to create a smaller backup that is effective for installing domain controllers from restored backup media. Note To back up system state, you must log on locally to the domain controller, or Remote Desktop must be enabled on the remote domain controller so that you can connect remotely. Administrative credentials To perform the following two procedures, you must be a member of the Domain Admins group or a member of the Backup Operators group. To back up system state including system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. This procedure provides steps for backing up in Wizard Mode. By default, the Always Start in Wizard Mode check box is selected in the Backup or Restore Wizard. If the Welcome to the Backup Utility Advanced Mode page appears, click Wizard Mode to open the Backup or Restore Wizard.

2. On the Welcome to the Backup or Restore Wizard page, click Next. 3. Select Back up files and settings, and then click Next. 4. Select Let me choose what to back up, and then click Next. 5. In the Items to Back Up window, double-click My Computer. 6. In the expanded list below My Computer, check System State, and then click Next. 7. Select a location to store the backup: If you are backing up to a file, type the path and file name for the backup (.bkf) file (or click Browse to find a folder or file). If you are backing up to a tape unit, choose the tape that you want to use. Note You should not store the backup on the local hard drive. Instead, store it in a location, such as a tape drive, away from the computer that you are backing up. 8. Type a name for this backup according to the recommendations in Backing Up Active Directory Components, and then click Next. 9. On the last page of the wizard, click Advanced. 10. Do not change the default options for Type of Backup. Normal should be selected, and the check box for Backup migrated remote storage data should remain cleared. Click Next. 11. Select Verify data after backup, and then click Next. 12. In the Backup Options dialog box, select a backup option, and then click Next. 13. If you are replacing the existing backups, select the option to allow only the owner and administrator access to the backup data and to any backups that are appended to this medium, and then click Next. 14. In the When to back up box, select the appropriate option for your needs, and then click Next. 15. If you are satisfied with all of the options that are selected, click Finish to perform the backup operation according to your selected schedule. Note The system state can also be backed up by using Ntbackup from a

command line with appropriate parameters. For more information, at a command prompt type ntbackup /?. The following procedure produces a smaller .bkf file that does not include system boot files. By using this procedure, you can reduce the time that is required to perform the backup and subsequent restore, as well as the amount of disk space that is required. This method is recommended when the restored backup is to be used for installing additional domain controllers. To back up system state excluding system-protected files 1. To start the Windows Server 2003 backup utility, click Start, click Run, type ntbackup, and then click OK. 2. On the Welcome to the Backup or Restore Wizard page, click Advanced Mode, and then click the Backup tab. 3. In the console tree, select the System State check box. 4. In Backup media or file name, type a name for this backup according to the recommendations in Backing Up Active Directory Components. 5. Click Start Backup, and then click Advanced. 6. Clear the Automatically back up System Protected Files with the System State check box, and then click OK. 7. Click Start Backup.

See Also
Enable Remote Desktop Create a Remote Desktop Connection

Restore system state to an alternate location


Perform this procedure to create media for installing a domain controller from restored backup media or to allow an authoritative restore of SYSVOL. After the domain controller installation is complete, delete the files in the alternate location.

You can restore the system state backup to an alternate location on the domain controller from which the backup was made, a location on another computer, or a location on the computer that you want to install as a domain controller. Administrative credentials To perform this procedure, you must be a member of the Backup Operators group, as follows: Restore system state on a member or workgroup server: Backup Operators group on the local computer Restore system state on a domain controller: Backup Operators group in the domain To restore system state to an alternate location 1. Log on to the server that has the alternate location to which you are restoring system state backup files. 2. Click Start, click Run, type ntbackup, and then click OK. 3. On the Welcome to the Backup or Restore Wizard page, click Next. 4. Click Restore Files and settings, and then click Next. 5. On the What to Restore page, click Browse, and then, in the Open Backup File dialog box, click Browse again. 6. Navigate to the .bkf file that you want to restore to an alternate location. The .bkf file can be located in a folder on the current computer, in a shared folder on the backup computer or other network computer, or on an external drive that contains removable media. 7. In the Select file for catalog dialog box, click the .bkf file that you want to restore, and then click Open. 8. In the Open Backup File dialog box, click OK. 9. In Items to restore, double-click File, and then double-click the .bkf file that you want to restore. 10. Below the .bkf file that you want to restore, select the System State check box, and then click Next. (You do not need to restore the system disk to an alternate location.) 11. On the Completing the Backup or Restore Wizard page, click Advanced. 12. In the Restore Files to drop-down list, click Alternate Location.

13. In Alternate Location, type the path (or browse) to the local folder to which you are restoring the backup, and then click Next. We recommend restoring to a folder named NTDSRESTORE, if space permits, on the volume that will host the Ntds.dit file when Dcpromo is run. Otherwise, restore to a folder named \NTDSRESTORE on another volume that has sufficient free space. 14. On the How to Restore page, accept the default selection Leave existing files (Recommended), and then click Next. 15. On the Advanced Restore Options page, accept the default selections Restore security settings and Preserve existing volume mount points, and then click Next. 16. On the Completing the Backup or Restore Wizard page, click Finish.

Enable Remote Desktop


You can enable Remote Desktop on the server that you are installing as a domain controller so that service administrators can manage the domain controller remotely. Remote Desktop is disabled by default in Windows Server 2003 operating systems. Use this procedure to enable remote desktop prior to shipping the server that will be installed as a domain controller. If you neglected to perform this procedure prior to shipping the server, use the procedure "To enable Remote Desktop remotely by using the registry," later in this topic Administrative credentials To complete this procedure, you must be a member of the local Administrators group. To enable Remote Desktop 1. Click Start, point to Control Panel, and then click System.Or Click Start, right-click My Computer, and then click Properties. 2. On the Remote tab, under Remote Desktop, select the Allow users to connect remotely to this computer check box, and then click OK. Note On computers running Windows Server 2003 with Service Pack 1 (SP1), on the Remote tab, select the Enable Remote Desktop on this computer check box.

If for any reason you neglected to perform this procedure prior to shipping the server, you can enable Remote Desktop remotely by using the registry. Administrative credentials To complete this procedure, you must be a member of the local Administrators group. To enable Remote Desktop remotely by using the registry 1. On any computer that is running a version of Windows Server 2003 or Windows XP Professional, click Start, click Run, type regedit, and then click OK. 2. On the File menu, click Connect Network Registry. 3. In the Select Computer dialog box, type the computer name and then click Check Names. 4. In the Enter Network Password dialog box, provide Domain Admins credentials for the domain of the server, and then click OK. 5. After the computer name resolves, click OK. 6. In the computer node that appears in the Registry Editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server. 7. In the console tree, click Terminal Server and then, in the details pane, double-click fDenyTSConnections. 8. In the Edit DWORD Value box, in Value data, type 0, and then click OK. 9. To implement the change, reboot the server remotely, as follows: Open a command prompt, type the following, and then press Enter: shutdown -m \\DomainControllerName -r

Create an answer file for domain controller installation


Use this procedure to create a text file that you can use as the answer file for an unattended installation of a domain controller. The answer file contains sensitive information and should be kept in a secure location. Administrative credentials

To perform this procedure, you must be a member of the Authenticated Users group on the local computer on which you create the answer file. To create an answer file for domain controller installation 1. On a local computer, insert the Windows Server 2003 CD-ROM into the CDROM drive or DVD-ROM drive. Press and hold down the SHIFT key as you insert the CD to prevent it from starting automatically. 2. Start Windows Explorer, and then open the Support\Tools folder on the Windows Server 2003 CD-ROM. 3. In the console tree, click Tools, and then, in the details pane, double-click Deploy.cab. 4. In the details pane, right-click Ref.chm, and then click Extract. 5. In the Select a Destination dialog box, navigate to or create a new folder for the expanded Ref.chm file, and then click Extract. 6. In its extracted location, open Ref.chm. 7. On the Contents tab in the scope pane, double-click Unattend.txt, and then click [DCInstall]. 8. In the details pane, scroll to Sample, select the entire sample, beginning at [DCInstall], and then copy the sample. 9. Open Notepad, paste the sample into the Notepad file, and save the text file. 10. Edit the text file to contain at least the following entries (additional entries and their descriptions are available in Ref.chm): [DCINSTALL] UserName=SAM account name that has Domain Admins credentials in the target domain. This account must be used by the administrator who runs the Dcpromo command. Password=Password for the account name. If you leave this blank, Dcpromo prompts the user during installation. Dcpromo deletes this value following installation. UserDomain=Domain name for the user account in UserName. DatabasePath=Location of the Ntds.dit file. (The default is %systemroot%\ntds.) If you omit this entry, Dcpromo uses the default location. LogPath=Location of the database log files. (The default is %systemroot%\ntds.)

If you omit this entry, Dcpromo uses the default location. SYSVOLPath=Location of the shared SYSVOL tree. (The default is %systemroot %\ntds.) If you omit this entry, Dcpromo uses the default location. SafeModeAdminPassword=Password for the administrator account that must be used to start the domain controller in Directory Services Restore Mode. If you leave this blank, Dcpromo prompts the user for the password during installation. Dcpromo deletes this value following installation. Passwords are removed from the answer file when Dcpromo is executed. CriticalReplicationOnly=Yes or no, to specify whether to skip noncritical portions of replication and allow Dcpromo to complete before replication is complete. SiteName=The name of the Active Directory site in which this domain controller will be placed. This site must be created in advance in the Active Directory Sites and Services snap-in. ReplicaOrNewDomain=Specify either Replica for an additional domain controller in an existing domain or NewDomain for the first domain controller in a new domain. ReplicaDomainDNSName=The fully qualified domain name of the domain of the new domain controller. ReplicationSourceDC=The name of an existing domain controller in the domain to use as the source replication partner during installation. When you install Active Directory from restored backup media, you can use this entry in conjunction with ReplicateFromMedia if you want to specify the domain controller from which Active Directory changes and SYSVOL changes are replicated. ReplicateFromMedia=Yes for installation from media, no for installation by replication. ReplicationSourcePath=When the installation is by replication, the path to the installation CD or network share. When the installation is from restored backup media, the local drive and path to the restored backup files. RebootOnSuccess=Yes if you want the domain controller to restart automatically following a successful installation, no if you want to restart the domain controller manually. If you do not want the domain controller to restart automatically and you do not want to be prompted, use the value NoAndNoPromptEither. ApplicationPartitionsToReplicate=Comma-separated distinguished names, with the entire string enclosed in quotation marks, of application directory partitions that you want to include when you use restored backup media to install Active Directory (or * to include all application directory partitions). Using this entry

requires Windows Server 2003 with Service Pack 1 (SP1) and Windows Server 2003 forest functional level. For more information about using this entry, see Include application directory partitions in an Active Directory installation from backup media. 11. Save the answer file to the location on the installation server from which it is to be called by Dcpromo, or save the file to a network share or removable media for distribution.

See Also
Include application directory partitions in an Active Directory installation from backup media

Create a Remote Desktop Connection


If Remote Desktop is enabled on a server, you can use Remote Desktop Connection to connect to the server and manage it remotely. Remote Desktop is disabled by default in Windows Server 2003 operating systems. Administrative credentials To complete this procedure, you must have Remote Desktop permissions by being added to the Remote Desktop Users group or you must be a member of the local Administrators group of the computer to which you are connecting. If the computer is a domain controller, you must have the Allow Logon Locally right applied in the Default Domain Controllers Policy. To create a new Remote Desktop Connection 1. On the Start menu, point to Programs or All Programs, point to Accessories, point to Communications, and then click Remote Desktop Connection. 2. In Computer, type a computer name or Internet Protocol (IP) address, and then click Connect. The computer can be a terminal server, or it can be a computer running Windows XP Professional or a Windows Server 2003 operating system that has Remote Desktop enabled and for which you have Remote Desktop permissions. 3. In the Log On to Windows dialog box, type your user name, password, and domain (if required), and then click OK.

See Also
Enable Remote Desktop

Install Active Directory from restored backup media


Use this procedure to install Active Directory from backup media to create an additional domain controller in an existing domain. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain into which you are installing the additional domain controller. To install Active Directory from restored backup media 1. Click Start, click Run, type dcpromo /adv, and then press ENTER. 2. In the Active Directory Installation Wizard, select Additional domain controller for existing domain. 3. Select From these restored backup files, and point to the same location where you restored the system state data. 4. If the domain controller whose system state backup you are using is a global catalog server, the Active Directory Installation Wizard asks you whether you want this server to also be a global catalog server. 5. Give appropriate credentials for the operation. 6. Enter the domain of the new domain controller. This domain must be the domain of the domain controller whose system state backup you are using. 7. Complete the remaining pages of the Active Directory Installation Wizard. Dcpromo.exe will install Active Directory using the data present in the restored files, which eliminates the need to replicate every object from a partner domain controller. However, objects that were modified, added, or deleted since the backup was taken must be replicated. If the backup was recent, the amount of replication required will be considerably less than that required for a regular Active Directory installation. After the installation operation completes successfully and the computer is restarted, the folder and subfolders that contain the restored system state can be

removed from the local disk.

See Also
Restore system state to an alternate location Include application directory partitions in an Active Directory installation from backup media

Include application directory partitions in an Active Directory installation from backup media
You can use this procedure to install Active Directory from restored backup media that includes application directory partitions to create an additional domain controller in an existing domain. In this procedure, you edit a domain controller installation answer file to provide instructions for including application directory partitions in the installation. You must have already created the answer file according to the directions in Create an answer file for domain controller installation. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain into which you are installing the additional domain controller. To include application directory partitions in an Active Directory installation from backup media 1. Open the answer file that you created to install the domain controller. 2. To include application directory partitions that are contained in the system state backup, add the following entry to the end of the answer file: ApplicationPartitionsToReplicate= 3. Provide a value for ApplicationPartitionsToReplicate as follows: If you want to include all application directory partitions, use the value *.

If you want to include specific application directory partitions, type the distinguished name of each directory partition. Separate each distinguished name with a space, and enclose the entire list in quotation marks, as shown in the following example:

ApplicationPartitionsToReplicate="dc=app1,dc=contoso,dc=com dc=app2,dc=contoso,dc=com" 4. In the entry ReplicationSourcePath=, type the path to the folder that contains the restored system state backup files on the installation computer. 5. If you do not want Dcpromo to prompt the user for passwords, type the password in the Password= entry for the account that you will use to install the domain controller, type the password in the SafeModeAdminPassword= entry that you will use to provide access to Directory Services Restore Mode, and then save the answer file. Note Passwords are automatically deleted from the answer file when Dcpromo runs. 6. Open a command prompt, and then change directories to the location of the answer file. 7. At the command prompt, type the following command, and then press ENTER: dcpromo /adv /answer:"Drive:\PathToAnswerFile\AnswerFileName" Active Directory installation occurs automatically. If you left passwords blank in the answer file, Dcpromo prompts you for your administrative password and for the Directory Services Restore Mode password. If you specified "no" for the RebootOnSuccess= entry in the answer file, Dcpromo prompts you to restart the server after installation.

Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection


When you ship a domain controller to a remote site, you must disconnect it from the network and, consequently, from the replication topology. If a domain controller must be separated from the replication topology for a period of time that might be longer than a tombstone lifetime, you must take preliminary steps to ensure a smooth reconnection. Otherwise, it is possible that a long-term disconnection can result in a deleted object being reintroduced into the directory. Such deleted objects, when they are retained on a domain controller that has been disconnected for a period that is longer than a tombstone lifetime,

are called "lingering objects." Lingering objects that are security principals, such as users or groups, can cause problems with Active Directory searches and e-mail delivery. Lingering objects can also jeopardize security if a user is allowed access to a resource by virtue of membership in a group that has been deleted. For more information about lingering objects, see "Maintaining Directory Consistency When Disconnecting a Domain Controller" in Known Issues for Adding Domain Controllers in Remote Sites. By taking preliminary precautions, you can ensure that long-term disconnections do not result in directory inconsistency from lingering objects. To complete this task, perform the following procedures: 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 your design or deployment team. If the anticipated time of disconnection exceeds the maximum safe disconnection period, make a decision about whether to extend the tombstone lifetime. To change the tombstone lifetime, see Determine the tombstone lifetime for the forest and change the value in the tombstoneLifetime attribute. 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 the domain-level operations master roles, if appropriate. 6. Transfer the schema master, if appropriate. 7. Transfer the domain naming master, if appropriate. 8. Prepare a domain controller for nonauthoritative SYSVOL restart on the domain controller that you are disconnecting. This process ensures an up-to-date SYSVOL when the domain controller is restarted. This process might result in a new copy of SYSVOL being replicated from another domain controller in the domain. To avoid full replication of SYSVOL, additional preparation is required. For more information about ensuring that SYSVOL does not require full synchronization following restart, see "Seeding the SYSVOL tree from restored files during IFM promotion" in article 311078, "How to use the Install from Media feature to promote Windows Server 2003-based domain controllers," in the Microsoft Knowledge Base on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=37924). These instructions are not specific to

installing from backup media, but they apply to preparing SYSVOL on any domain controller so that full synchronization is not required. 9. Enable strict replication consistency on the domain controller that you are disconnecting. You can use this command-line procedure as an option to enable strict replication consistency on additional other domain controllers or on all domain controllers in the forest. 10. Synchronize replication with all partners. Update the domain controller with the latest changes just before you disconnect it. 11. Verify successful replication to a domain controller for the domain controller that you are disconnecting. 12. Label the domain controller with the date and time of disconnection and the maximum safe disconnection period.

See Also
Known Issues for Adding Domain Controllers in Remote Sites Managing Operations Master Roles Managing SYSVOL Reconnecting a Domain Controller After a Long-Term Disconnection Windows Server 2003 Technical Reference

Determine the tombstone lifetime for the forest


The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition. Administrative Credentials To complete this procedure, you must be a member of the Domain Users group. To determine the tombstone lifetime for the forest 1. On the Start menu, click Run, type adsiedit.msc, and then click OK. 2. In the console tree, double-click Configuration [DomainControllerName], CN=Configuration,DC=[ForestRootDomain], CN=Services, and

CN=Windows NT. 3. Right-click CN=Directory Service, and then click Properties. 4. In the Attribute column, click tombstoneLifetime. 5. Note the value in the Value column. If the value is <not set>, the default value is in effect as follows: On a domain controller in a forest that was created on a domain controller running Windows Server 2003 with Service Pack 1 (SP1), the default value is 180 days. On a domain controller in a forest that was created on a domain controller running Windows 2000 Server or Windows Server 2003, the default value is 60 days.

View the current operations master role holders


Once an operations master role has been transferred, it should be verified that the transfer has occurred successfully throughout the domain. The change must be replicated to all relevant domain members in order to truly take effect. 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. Administrative Credentials To perform this procedure, you must be logged on as a User or an Administrator. To view the current operations master role holder 1. Click Start, click Run, type ntdsutil, and then press ENTER. 2. At the ntdsutil: prompt, type roles and press ENTER. 3. At the fsmo maintenance: prompt, type connections and press ENTER. 4. 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). 5. After receiving confirmation of the connection, type quit and press ENTER to

exit this menu. 6. At the fsmo maintenance: prompt, type select operation target and press ENTER. 7. 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 currently assigned to host each role. 8. 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.

Transfer the domain-level operations master roles


Use this procedure to transfer the three domain-level operations master roles: 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. Note 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To transfer a domain-level operations master role 1. Open Active Directory Users and Computers. 2. At the top of the console tree, right-click Active Directory Users and Computers. Click Connect to Domain Controller. 3. In the list of available domain controllers, click the name of the server to which you want to transfer the role, and then click OK.

4. At the top of the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Masters. The name of the current operations master role holder appears in the Operations master box. The name of the server to which you want to transfer the role appears in the lower box. 5. Click the tab for 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, and then click OK. 6. Repeat steps 4 and 5 for each role that you want to transfer.

Transfer the schema master


Use this procedure to transfer the schema operations master role. The schema master is a forest-wide operations master role. Before you can use the Active Directory Schema snapin for the first time, you must register it with the system. If you have not yet prepared the Active Directory Schema snap-in, see Install the Schema snap-in before you begin this procedure. Note This procedure is performed by using the Microsoft Management Console (MMC), although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, type ? at the Ntdsutil.exe command prompt. Administrative Credentials To perform this procedure, you must be a Schema Administrator in Active Directory. Transfer the schema master 1. Open the Active Directory Schema snap-in. 2. In the console tree, right-click Active Directory Schema, and click Change Domain Controller. 3. In the Change Domain Controller dialog box, click Specify Name. Then, in the text box, type the name of the server to which you want to transfer the schema master role. Click OK.

4. In the console tree, right-click Active Directory Schema. Click Operations Master. The Change Schema Master box displays the name of the server that is currently holding the role. The targeted domain controller is listed in the second box. 5. Click Change. Click Yes to confirm your choice. The system confirms the operation. Click OK again to confirm that the operation succeeded. 6. Click Close to close the Change Schema Master dialog box. 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.

Transfer the domain naming master


Use this procedure to transfer the domain naming operations master role. The domain naming master is a forest-wide operations master role. Note This procedure is performed by using the Microsoft Management Console (MMC), although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, type ? at the Ntdsutil.exe command prompt. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory. To transfer the domain naming master 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller. 3. Ensure that the proper domain name is entered in the Domain box. The available domain controllers from this domain are listed.

4. In the Name column, click the domain controller (to select it) to which you want to transfer the role. Click OK. 5. Right-click Active Directory Domains and Trusts, and then click Operations Master. 6. 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. 7. Click Change. To confirm the role transfer, click Yes. Click OK again to close the message box indicating the transfer took place. Click Close to close the Change Operations Master dialog box.

Prepare a domain controller for nonauthoritative SYSVOL restart


Initiate a nonauthoritative restart 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 nonauthoritative restart of SYSVOL when the domain controller is restarted. Separate entries exist for global and replica-set-specific BurFlags, as follows: To initiate a nonauthoritative restart 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 If other replica sets are represented on the domain controller and you want to update 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.

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 Administering Active Directory Backup and Restore. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To prepare a domain controller for nonauthoritative SYSVOL restart 1. Click Start, click Run, type regedit and then click OK. 2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters 3. Expand Parameters. 4. Modify one of the BurFlags entries as follows: To modify the global BurFlags entry: a. Expand Backup/Restore and then click Process at Startup. b. In the details pane, right-click BurFlags and click Modify. c. In the Value data box, type D2 hexadecimal or 210 decimal.

d. Click OK and close Registry Editor. To modify the replica-set-specific BurFlags entry: a. Expand both Cumulative Replica Sets and Replica Sets. b. Match the GUID under Replica Sets to the identical GUID under Cumulative Replica Sets, and click the matching GUID under Cumulative Replica Sets. c. In the details pane, right click BurFlags and click Modify.

d. In the Value data box, type D2 hexadecimal or 210 decimal. e. Click OK and close Registry Editor.

Enable strict replication consistency


The setting for replication consistency is stored in the registry in the Strict Replication Consistency entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Values for this entry are as follows: Value: 1 (0 to disable) Default: 1 (enabled) in a new Windows Server 2003 forest; otherwise 0. Data type: REG_DWORD

On domain controllers running Windows Server 2003 with Service Pack 1 (SP1), you do not have to edit the registry directly to enable strict replication consistency. It is best to avoid editing the registry directly if possible. You can use a Repadmin command that enables strict replication consistency on one or all domain controllers in the forest. This command is available only in the version of Repadmin that is included with Windows Support Tools in Windows Server 2003 SP1. This command can be applied only on domain controllers running Windows Server 2003 with SP1. Administrative credentials To complete this procedure on a single domain controller, you must be a member of the Domain Admins group in the domain. To complete this procedure on all domain controllers, you must be a member of the Enterprise Admins group in the forest. Requirements: Operating system: Windows Server 2003 with SP1 Note To enable strict replication consistency on a domain controller that is not running Windows Server 2003 with SP1, use a registry editor to set the value in the Strict Replication Consistency entry to 1. Caution It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft

Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution. To enable strict replication consistency 1. Open a command prompt, type the following command, and then press ENTER: repadmin /regkey DC_LIST {+|-}key Term DC_LIST Definition The name of a single domain controller. (* applies the change to all domain controllers in the forest.) For the domain controller name, you can use the Domain Name System (DNS) name, the distinguished name of the domain controller computer object, or the distinguished name of the domain controller server object. + to enable and - to disable, and key is strict. For example, +strict enables strict replication consistency; -strict disables it.

{+|-}key

2. Repeat step 1 for every domain controller on which you want to enable strict replication consistency. Note For more naming options and information about the syntax of the DC_LIST parameter, at the command prompt type repadmin /listhelp.

Synchronize replication with all partners


You can use this procedure to synchronize replication with all replication partners of a domain controller. Administrative credentials

To perform this procedure, you must be a member of the Domain Admins group in the domain of the selected domain controller or the Enterprise Admins group in the forest, or you must have been delegated the appropriate authority. If you want to synchronize the configuration and schema directory partitions on a domain controller in a child domain, you must have Domain Admins credentials in the forest root domain or Enterprise Admins credentials in the forest. To synchronize replication with all partners 1. At a command prompt, type the following command, and then press ENTER: repadmin /syncall DCName /e /d /A /P /q Term DCName Definition The Domain Name System (DNS) name of the domain controller on which you want synchronize replication with all partners Enterprise; includes partners in all sites. Identifies servers by distinguished name in messages. All; synchronizes all directory partitions that are held on the home server. Pushes changes outward from the home server. Runs in quiet mode; suppresses callback messages.

/e /d /A /P /q

2. Check for replication errors in the output of the command in the previous step. If there are no errors, replication is successful. For replication to complete, any errors must be corrected.

See Also
Verify successful replication to a domain controller

Verify successful replication to a domain controller


You can use the repadmin /showrepl command to verify successful replication to a specific domain controller. If you are not running Repadmin on the domain controller whose replication you are checking, you can specify a destination domain controller in the command. Repadmin lists INBOUND NEIGHBORS for the current or specified domain controller. INBOUND NEIGHBORS shows the 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 replication succeeded or not, as follows: Last attempt @ YYYY-MM-DD HH:MM.SS was successful. Last attempt @ [Never] was successful.

If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the destination domain controller. To verify successful replication to a domain controller 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl servername /u:domainname\username /pw:* Term servername domainname Definition Specifies the name of the destination domain controller. Specifies the single-label name of the domain of the destination domain controller. (You do not have to use a fully qualified Domain Name System (DNS) name.) Specifies the name of an administrative account in that domain.

username

3. When you are prompted for a password, type the password for the user account that you provided, and then press ENTER. You can also use Repadmin to generate the details of replication to and from all replication partners in a spreadsheet. The spreadsheet displays data in the following columns: Showrepl_COLUMNS Destination DC Site Destination DC Naming Context Source DC Site Source DC Transport Type Number of Failures Last Failure Time Last Success Time Last Failure Status The following procedure shows how to create this spreadsheet and set column headers for improved readability. To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl * /csv >showrepl.csv 3. Open Microsoft Excel. 4. On the File menu, click Open, navigate to showrepl.csv, and then click Open. 5. Hide or delete column A as well as the Transport Type column, as follows: 6. Select a column that you want to hide or delete. To hide the column, on the Format menu, click Column, and then click Hide. Or

To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row, and then, on the Window menu, click Freeze Panes. 8. Select the entire spreadsheet. On the Data menu, click Filter, and then click AutoFilter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the down arrow, and then click Custom. 11. In the Custom AutoFilter dialog box, under Show rows where, click does not contain. In the adjacent text box, type del to eliminate from view the results for deleted domain controllers. 12. Repeat step 10 for the Last Failure Time column, but use the value does not equal, and type the value 0. 13. Resolve replication failures. The last successful attempt should agree with the replication schedule for intersite replication, or the attempt should be within the last hour for intrasite replication. If Repadmin reports any of the following conditions, see Troubleshooting Active Directory Replication Problems: The last successful intersite replication was prior to the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful.

See Also
Troubleshooting Active Directory Replication Problems

Reconnecting a Domain Controller After a Long-Term Disconnection


Assuming that a domain controller has not been disconnected for longer than the maximum safe period for disconnection (tombstone lifetime minus end-to-end replication latency), reconnecting the domain controller to the replication topology requires no special

procedures. By default, the Knowledge Consistency Checker (KCC) on a domain controller runs five minutes after the domain controller starts, automatically incorporating the reconnected domain controller into the replication topology.

Reconnecting an Outdated Domain Controller


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, reconnect the domain controller as follows: The disconnected domain controller is running Windows Server 2003, and an authoritative domain controller running Windows Server 2003 is available in this site or a neighboring site: Reconnect the domain controller, and immediately follow the instructions in Use Repadmin to remove lingering objects. The disconnected domain controller is running Windows Server 2003, but no other authoritative domain controller running Windows Server 2003 is available in the domain: Reconnect the domain controller, and follow the instructions in article 314282, "Lingering objects may remain after you bring an out-of-date global catalog server back online," in the Microsoft Knowledge Base on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=37924). The disconnected domain controller is running Windows 2000 Server, and another domain controller is available in the domain: Do not reconnect the domain controller. Instead, force Active Directory removal on the disconnected domain controller, perform metadata cleanup, and then reinstall Active Directory. To complete these tasks, follow the instructions in Forcing the Removal of a Domain Controller and Installing a Domain Controller in an Existing Domain. The disconnected domain controller is running Windows 2000 Server, and no other domain controller is available in the domain: If you want to recover the domain, reconnect the domain controller, and follow the instructions in article 314282, "Lingering objects may remain after you bring an out-of-date global catalog server back online," in the Microsoft Knowledge Base on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=37924).

Updating SYSVOL
As described in Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection, the recommended practice to ensure consistency of SYSVOL is to modify the registry before disconnecting the domain controller so that SYSVOL is updated

automatically when the domain controller is restarted. In addition, if you want to avoid a full synchronization of SYSVOL through intersite replication, you must take preparatory steps before disconnection. For information about how to ensure that SYSVOL is sourced locally and updated over the network only for changes, see "Seeding the SYSVOL tree from restored files during IFM promotion" in article 311078, "How to use the Install from Media feature to promote Windows Server 2003-based domain controllers," in the Microsoft Knowledge Base on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=37924). To update SYSVOL as soon as possible after reconnecting a domain controller, 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 replication schedule, and then restart the domain controller as soon as possible after replication is scheduled to start. If a replication partner for the domain is available within the site, verify replication success on that partner before restarting the domain controller. Important Do not use file copy utilities, such as Xcopy or Robocopy, to update an outdated SYSVOL. Copying SYSVOL files is recommended only for recreating a nonfunctioning SYSVOL, which requires several preliminary procedures. Copying SYSVOL files from one domain controller to another without following these procedures causes invalid data to be replicated and causes the system volumes on other domain controllers to become inconsistent. For information about how to recreate a nonfunctioning SYSVOL, see Restoring and Rebuilding SYSVOL. To complete this task, perform the following procedures: 1. Determine the tombstone lifetime for the forest. 2. Determine whether the maximum safe disconnection time has been exceeded. The maximum safe disconnection time should have been established at the time of disconnection, as follows: Subtract a generous estimate of the amount of time for 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 your design or deployment team. 3. If the maximum safe disconnection time has not been exceeded, proceed with the reconnection process as follows: 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 anytime.

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: Determine when intersite replication is scheduled to begin by viewing the replication properties on the site link that connects this site to the next closest site that includes a domain controller that is authoritative for this domain. As soon as possible after the next replication cycle begins, start the domain controller. If the maximum safe disconnection time has been exceeded, proceed in the appropriate manner according to the operating system, as described in "Reconnecting an Outdated Domain Controller" earlier in this topic. 4. After replication is complete, Verify successful replication to a 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.

See Also
Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection

Determine when intersite replication is scheduled to begin


You can use the properties on the site link object to determine when intersite replication between sites is scheduled to begin. Administrative Credentials To complete this procedure, you must be a member of the Domain Users group. To determine when intersite replication is scheduled to begin 1. Open Active Directory Sites and Services. 2. In the console tree, double-click the Sites container, double-click the Inter-Site Transports container, and then click the IP container. 3. In the details pane, right-click the site link object for which you want to view the schedule, and then click Properties.

4. In the SiteLinkName Properties dialog box, click Change Schedule. Note the block of days and hours during which replication is allowed (Replication Available), and then click OK. 5. 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, and then click OK.

Use Repadmin to remove lingering objects


You can use Repadmin to remove lingering objects when you reconnect a domain controller that has been offline for longer than a tombstone lifetime and you want to ensure that lingering objects do not exist or, if they do, that they are removed before they are replicated. You can also use this procedure when event ID 1388 or event ID 1988 is logged on a domain controller. In this case, the information that you need to perform the procedure is provided in the event. For information about removing lingering objects when event ID 1388 or event ID 1988 has been logged, see "Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)." If you are running the procedure preemptively, you must gather the following information before beginning the procedure: Name of the server that has or might have lingering objects. This name can be the Domain Name System (DNS) name, NetBIOS name, or distinguished name of the domain controller. Globally unique identifier (GUID) of the NTDS Settings object of a domain controller that is authoritative for the domain of the domain controller from which you want to remove lingering objects. If necessary, use the following procedure to determine the GUID of a domain controller. Administrative Credentials To complete this procedure, you must be a member of the Domain Users group in the domain of the domain controller. To determine the GUID of a domain controller 1. At a command prompt, type the following command, and then press ENTER:

repadmin /showreplDomainControllerName where DomainControllerName is the NetBIOS name of the domain controller whose GUID you want to determine. 2. In the top portion of the output, note the value in DC object GUID: If the destination domain controller and source domain controller are both running Windows Server 2003, you can remove lingering objects by using Repadmin. If either domain controller is running Windows 2000 Server, follow instructions in article 314282, "Lingering objects may remain after you bring an out-of-date global catalog server back online," in the Microsoft Knowledge Base on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=37924). Administrative Credentials To complete this procedure, you must be a member of the Domain Admins group in the DirectoryPartition domain. To use Repadmin to remove lingering objects 1. At a command prompt, type the following command, and then press ENTER: repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode Term ServerName ServerGUID DirectoryPartition Definition The DNS name or the distinguished name of the domain controller that has or might have lingering objects. The GUID of a domain controller that has an up-to-date writable replica of the directory partition The distinguished name of the domain directory partition that might have lingering objects. For example, DC=RegionalDomainName,DC=ForestRootDomainName,DC=com. Also run the command against the configuration directory partition (CN=configuration,DC=ForestRootDomainName,DC=com), the schema directory partition (CN=schema,CN=configuration,DC=ForestRootDomainName), and any application directory partitions that are hosted on the domain controller you are checking for lingering objects.

/advisory_mode logs the lingering objects that will be removed so that you can review

them, but it does not remove them. 2. If lingering objects are found, repeat step 1 without /advisory_mode to delete the identified lingering objects from the directory partition. 3. Repeat steps 1 and 2 for every domain controller that might have lingering objects. Note The ServerName parameter uses the DC_LIST syntax for repadmin, which allows the use of * for all domain controllers in the forest and gc: for all global catalog servers in the forest. To see the DC_LIST syntax, type repadmin /listhelp.

See Also
Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)

Verify successful replication to a domain controller


You can use the repadmin /showrepl command to verify successful replication to a specific domain controller. If you are not running Repadmin on the domain controller whose replication you are checking, you can specify a destination domain controller in the command. Repadmin lists INBOUND NEIGHBORS for the current or specified domain controller. INBOUND NEIGHBORS shows the 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 replication succeeded or not, as follows: Last attempt @ YYYY-MM-DD HH:MM.SS was successful. Last attempt @ [Never] was successful.

If @ [Never] appears in the output for a directory partition, replication of that directory partition has never succeeded from the identified source replication partner over the listed connection. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the destination domain controller.

To verify successful replication to a domain controller 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl servername /u:domainname\username /pw:* Term servername domainname Definition Specifies the name of the destination domain controller. Specifies the single-label name of the domain of the destination domain controller. (You do not have to use a fully qualified Domain Name System (DNS) name.) Specifies the name of an administrative account in that domain.

username

3. When you are prompted for a password, type the password for the user account that you provided, and then press ENTER. You can also use Repadmin to generate the details of replication to and from all replication partners in a spreadsheet. The spreadsheet displays data in the following columns: Showrepl_COLUMNS Destination DC Site Destination DC Naming Context Source DC Site Source DC Transport Type Number of Failures Last Failure Time Last Success Time Last Failure Status

The following procedure shows how to create this spreadsheet and set column headers for improved readability. To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: repadmin /showrepl * /csv >showrepl.csv 3. Open Microsoft Excel. 4. On the File menu, click Open, navigate to showrepl.csv, and then click Open. 5. Hide or delete column A as well as the Transport Type column, as follows: 6. Select a column that you want to hide or delete. To hide the column, on the Format menu, click Column, and then click Hide. Or To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row, and then, on the Window menu, click Freeze Panes. 8. Select the entire spreadsheet. On the Data menu, click Filter, and then click AutoFilter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the down arrow, and then click Custom. 11. In the Custom AutoFilter dialog box, under Show rows where, click does not contain. In the adjacent text box, type del to eliminate from view the results for deleted domain controllers. 12. Repeat step 10 for the Last Failure Time column, but use the value does not equal, and type the value 0. 13. Resolve replication failures. The last successful attempt should agree with the replication schedule for intersite replication, or the attempt should be within the last hour for intrasite replication.

If Repadmin reports any of the following conditions, see Troubleshooting Active Directory Replication Problems: The last successful intersite replication was prior to the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful.

See Also
Troubleshooting Active Directory Replication Problems

Performing an Unattended Installation of Active Directory


Running an unattended install simplifies the process of setting up Active Directory on multiple computers. The unattended install feature uses an answer file to provide answers to the questions that are asked during a normal setup. This way, the installation process can proceed from start to completion without user intervention. This method works best when Active Directory is installed with identical options on many computers. This method is required if you want to include application directory partitions in Active Directory installations from restored backup media. Task requirements The following tool is required to complete this task: Dcpromo.exe

The following files are required to complete this task: Ref.chm (in the Support\Tools folder on the Windows Server 2003 operating system CD) Unattend.txt Domain controller answer file

To complete this task, perform the following procedures: 1. Create an answer file for domain controller installation 2. Install Active Directory using an answer file

See Also
Include application directory partitions in an Active Directory installation from backup media

Create an answer file for domain controller installation


Use this procedure to create a text file that you can use as the answer file for an unattended installation of a domain controller. The answer file contains sensitive information and should be kept in a secure location. Administrative credentials To perform this procedure, you must be a member of the Authenticated Users group on the local computer on which you create the answer file. To create an answer file for domain controller installation 1. On a local computer, insert the Windows Server 2003 CD-ROM into the CDROM drive or DVD-ROM drive. Press and hold down the SHIFT key as you insert the CD to prevent it from starting automatically. 2. Start Windows Explorer, and then open the Support\Tools folder on the Windows Server 2003 CD-ROM. 3. In the console tree, click Tools, and then, in the details pane, double-click Deploy.cab. 4. In the details pane, right-click Ref.chm, and then click Extract. 5. In the Select a Destination dialog box, navigate to or create a new folder for the expanded Ref.chm file, and then click Extract. 6. In its extracted location, open Ref.chm. 7. On the Contents tab in the scope pane, double-click Unattend.txt, and then click [DCInstall]. 8. In the details pane, scroll to Sample, select the entire sample, beginning at [DCInstall], and then copy the sample. 9. Open Notepad, paste the sample into the Notepad file, and save the text file. 10. Edit the text file to contain at least the following entries (additional entries and their descriptions are available in Ref.chm):

[DCINSTALL] UserName=SAM account name that has Domain Admins credentials in the target domain. This account must be used by the administrator who runs the Dcpromo command. Password=Password for the account name. If you leave this blank, Dcpromo prompts the user during installation. Dcpromo deletes this value following installation. UserDomain=Domain name for the user account in UserName. DatabasePath=Location of the Ntds.dit file. (The default is %systemroot%\ntds.) If you omit this entry, Dcpromo uses the default location. LogPath=Location of the database log files. (The default is %systemroot%\ntds.) If you omit this entry, Dcpromo uses the default location. SYSVOLPath=Location of the shared SYSVOL tree. (The default is %systemroot %\ntds.) If you omit this entry, Dcpromo uses the default location. SafeModeAdminPassword=Password for the administrator account that must be used to start the domain controller in Directory Services Restore Mode. If you leave this blank, Dcpromo prompts the user for the password during installation. Dcpromo deletes this value following installation. Passwords are removed from the answer file when Dcpromo is executed. CriticalReplicationOnly=Yes or no, to specify whether to skip noncritical portions of replication and allow Dcpromo to complete before replication is complete. SiteName=The name of the Active Directory site in which this domain controller will be placed. This site must be created in advance in the Active Directory Sites and Services snap-in. ReplicaOrNewDomain=Specify either Replica for an additional domain controller in an existing domain or NewDomain for the first domain controller in a new domain. ReplicaDomainDNSName=The fully qualified domain name of the domain of the new domain controller. ReplicationSourceDC=The name of an existing domain controller in the domain to use as the source replication partner during installation. When you install Active Directory from restored backup media, you can use this entry in conjunction with ReplicateFromMedia if you want to specify the domain controller from which Active Directory changes and SYSVOL changes are replicated. ReplicateFromMedia=Yes for installation from media, no for installation by

replication. ReplicationSourcePath=When the installation is by replication, the path to the installation CD or network share. When the installation is from restored backup media, the local drive and path to the restored backup files. RebootOnSuccess=Yes if you want the domain controller to restart automatically following a successful installation, no if you want to restart the domain controller manually. If you do not want the domain controller to restart automatically and you do not want to be prompted, use the value NoAndNoPromptEither. ApplicationPartitionsToReplicate=Comma-separated distinguished names, with the entire string enclosed in quotation marks, of application directory partitions that you want to include when you use restored backup media to install Active Directory (or * to include all application directory partitions). Using this entry requires Windows Server 2003 with Service Pack 1 (SP1) and Windows Server 2003 forest functional level. For more information about using this entry, see Include application directory partitions in an Active Directory installation from backup media. 11. Save the answer file to the location on the installation server from which it is to be called by Dcpromo, or save the file to a network share or removable media for distribution.

See Also
Include application directory partitions in an Active Directory installation from backup media

Install Active Directory using an answer file


You can use this procedure to perform an unattended Active Directory installation by using an answer file. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain of the domain controller that you are installing. To install Active Directory using an answer file 1. Click Start, click Run, and then type dcpromo /answer:answerfile

Answerfile

The path to the answer file, including the filename. 2. Click OK.

See Also
Create an answer file for domain controller installation Include application directory partitions in an Active Directory installation from backup media Verifying Active Directory Installation

Verifying Active Directory Installation


There are several verification tasks that can be performed on a computer on which Active Directory has been newly installed. Successfully completing the requirements of each verification task will provide a strong indication of a healthy, operational domain controller. Task Requirements The following tools are recommended to perform the procedures for this task: Active Directory Sites and Services DNS Manager Event Viewer Netdiag.exe Dcdiag.exe Ntdsutil.exe

To complete this task, perform the following procedures: 1. Determine whether a Server object has child objects 2. Verify that an IP address maps to a subnet and determine the site association 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. 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. Note 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 must move the Server object after the server is restarted. 3. Move the Server object to the new site 4. Configure DNS server forwarders 5. Complete all procedures for the Verifying DNS configuration task. 6. Check the status of the shared SYSVOL 7. Verify DNS registration and functionality 8. Verify domain membership for a new domain controller 9. Verify communication with other domain controllers 10. Verify replication with other domain controllers 11. Verify the availability of the operations masters

Determine whether a Server object has child objects


After Active Directory is properly installed on a domain controller, the Server object for the domain controller will have a Child NTDS-Settings object. Other applications that are running on domain controllers can also publish Child objects. Prior to deleting a Server object from the Servers container for a site, verify that the Server object has no Child objects. If a Child object appears, do not delete the Server object. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To determine whether a server object has child objects 1. Open Active Directory Sites and Services. 2. Expand the Sites container and expand the site of the Server object. 3. Expand the Servers container, and then expand the Server object to view any

Child objects.

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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To verify that an IP address maps to a subnet and determine the site association 1. Log on locally or open a Terminal Services connection to the server for which you want to check the IP address. 2. On the desktop, right-click My Network Places, and then click Properties. 3. In the Network Connections dialog box, right-click Local Area Connection, and then click Properties. 4. Double-click Internet Protocol (TCP/IP). 5. Use the values in IP address and Subnet mask to calculate the subnet address and then click OK. 6. Click OK again and close the Network Connections dialog box. 7. Open Active Directory Sites and Services. 8. Expand the Sites container, and then click the Subnets container.

9. In the Name column in the details pane, find the Subnet object that matches the subnet address. 10. 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.

Move the Server object to the new 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. Before performing this procedure, verify that the IP address maps to the target site. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group. To move the server object to the new site 1. Open Active Directory Sites and Services. 2. Expand the Sites container and the site in which the server object resides. 3. Expand the Servers container to display the domain controllers that are currently configured for that site. 4. Right-click the Server object you want to move, and then click Move. 5. In the Site Name box, click the destination site, and then click OK. 6. Expand the Site object to which you moved the server, and then expand the Servers container. 7. Verify that an object for the server you moved exists. 8. 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 sitespecific 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.

Configure DNS server forwarders


Configure DNS server forwarders based on the forwarders method established on your network. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To configure DNS server forwarders 1. If your network uses root hints as the forwarders method, you do not need to perform any additional options. Root hints are automatically configured during installation. Do not continue to step 2. 2. If you need to configure forwarders, open the DNS snap-in and continue to step 3. 3. In the console tree, right-click ComputerName (where ComputerName is the computer name of the domain controller), and then click Properties. 4. In the ComputerName Properties sheet (where ComputerName is the name of the domain controller), on the Forwarders tab, select the Enable forwarders check box. 5. In the IP address box, type IpAddress (where IpAddress is the IP address of the DNS server or nearest replication partner from which the domain is delegated), click Add, and then click OK.

Verifying DNS configuration


Part of verifying Active Directory installation is verifying that DNS was installed and configured appropriately. Task Requirements The following tools are required to perform the procedures for this task:

DNS snap-in My Network Places

To complete this task, perform the following procedures: 1. Create a delegation for a domain controller 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. If your forest root domain has a parent DNS domain, perform this procedure on a DNS server in the parent domain. If you just added a new domain controller to a child domain, perform this procedure on a DNS server in the DNS parent domain. By following recommended practices, the parent domain is the forest root domain. 2. Configure the DNS client settings 3. Create a secondary zone

Create a delegation for a domain controller


Use this procedure to create a delegation for a new domain controller that is also a DNS server in the parent DNS domain. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To create a delegation for a domain controller 1. Open the DNS snap-in. 2. Navigate to ChildDomain (where ChildDomain is the name of the child domain) in the console tree. 3. In the console tree, right-click ChildDomain, and then click Properties. 4. In the ChildDomain Properties sheet, on the Name Servers tab, click Add. 5. In the New Resource Record dialog box, in the Server fully qualified domain name (FQDN) box, type ChildDC.ChildDomain.ParentDomain (where ChildDC is the name of the new domain controller, ChildDomain is the name of the child domain, and ParentDomain is the name of the parent domain).

6. In the New Resource Record dialog box, in the IP address box, type IPAddress (where IPAddress is the IP address of the child domain controller), click Add, and then click OK.

Create a secondary zone


Perform this procedure only on new domain controllers that are also DNS servers that are located in the child domain, not the forest root domain. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To create a secondary zone 1. Open the DNS snap-in. 2. In the console tree, right-click the new domain controller and click New Zone. 3. In the New Zone Wizard, click Next to continue. 4. On the Zone Type page, select Secondary zone and click Next. 5. Ensure that Forward lookup zone is selected. Click Next. 6. For Zone name, type _msdcs.forestrootdomain (where forestrootdomain is the fully qualified domain name of the forest root domain), and click Next. 7. In the Master DNS Servers dialog box, enter the IP addresses of at least two DNS servers in the forest root domain. Click Next. 8. Review the settings you defined, and click Finish to close the wizard.

Configure the DNS client settings


Configure the DNS client settings on the new domain controller. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group.

To configure the DNS client settings 1. On the desktop, right-click My Network Places and click Properties. 2. In the Network 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. 3. In the Local Area Connection Properties dialog box, click once on Internet Protocol (TCP/IP) to highlight it (be sure you do not clear the check box in front of it), then click Properties. 4. In the Internet Protocol (TCP/IP) Properties dialog box, verify that Use the following DNS server addresses: is selected. 5. 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. 6. Click OK to close the dialog box.

Check the status of the shared SYSVOL


This procedure involves checking Event Viewer to make sure that the File Replication service is started properly and then ensuring that the SYSVOL and Net Logon shared folders are created. Note You do not need to perform this procedure on every replication partner, but you need to perform it enough times to be confident that the shared system volumes on the replication partners are healthy. Administrative Credentials

To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To check the status of the shared SYSVOL 1. Open Event Viewer. 2. In the Event Viewer tree, click File Replication Service to display the FRS events. 3. 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 has started successfully. Event 13516 indicates that the service is started, the folders are shared, and the domain controller is functional. 4. 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 Net Logon and SYSVOL. 5. At a command prompt, type dcdiag /test:netlogons and press ENTER. 6. 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 Net Logon and SYSVOL shared folders.

Verify DNS registration and functionality


This procedure verifies that DNS is functioning so that other domain controllers can be located. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To verify DNS registration and functionality 1. Open a Command Prompt.

2. Type the following command and then press ENTER: netdiag /test:dns Note For a more detailed response from this command, add /v to the end of the command. 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 with 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 communication with other domain controllers


This procedure verifies that domain controllers can be located. Administrative Credentials To perform this procedure, you must be a member of the Domain users group in Active Directory. To verify communication with other domain controllers 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:dsgetdc Note For a more detailed response from this command, add /v to the end of the command. 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 replication with other domain controllers


The tests performed in this procedure 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To verify replication is functioning 1. Open a Command Prompt. 2. Type the following command, and then press Enter: dcdiag /test:replications Note For this set of tests, the /v option is available. However, it does not display any significant additional information. Messages indicate that the connectivity and replications tests passed. 3. To verify that the proper permissions are set for replication, type the following command and then press Enter: dcdiag /test:netlogons Messages indicate that the connectivity and netlogons tests passed.

Verify the availability of the operations masters


This procedure verifies that the operations masters can be located and that they are online and responding. Administrative Credentials To perform this procedure, you must be a member of the Domain users group in Active Directory. Note You can use these tests prior to installing Active Directory as well as afterward. 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. 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 test. 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 by adding /v to the end of the command to see the detailed response. To verify the availability of the operations masters 1. Open a Command Prompt. 2. Type the following command to ensure that the operations masters can be located and then press ENTER: dcdiag /s: domaincontroller /test:knowsofroleholders /verbose 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 the 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. Press ENTER. 3. Type the following command to ensure that the operations masters are functioning properly and are available on the network: 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. Press ENTER. 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.

Verify domain membership for a new domain controller


This test verifies that a new domain controller has successfully 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To verify domain membership for a new domain controller 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:member 3. It the test was successful you should see the following message: Domain membership test Passed. 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.

Renaming a Domain Controller


The ability to rename domain controllers running Windows Server 2003 (contrary to Windows 2000 Server) provides you with the flexibility to: Restructure your network for organizational and business needs. Make management and administrative control easier.

Renaming a domain controller is a common operation in many organizations and usually occurs when: New hardware is purchased to replace an existing domain controller.

Domain controllers are decommissioned, or promoted, and renamed to maintain a naming convention. Domain controllers are moved or placed in sites.

Note It is important to note that domain controller names have a primary impact on administration, rather than client access. Renaming a domain controller is an optional exercise, and the impacts should be well understood prior to renaming. Although you can use the System Properties user interface (UI) to rename a domain controller (as you can for any computer), Active Directory and DNS replication latency might temporarily prevent clients from locating or authenticating to the renamed domain controller, or both. To avoid this delay, use the Netdom command-line tool to rename a domain controller. Task requirements The following tools are required to perform the procedures for this task: System Properties or Netdom.exe Ldp.exe or Adsiedit.msc

If you want to use Netdom, the domain functional level must be set to Windows Server 2003. To complete this task, use one of the following two sets of procedures: 1. Rename a domain controller using System Properties 2. Update the FRS member object Or 1. Rename a domain controller using Netdom

2. Update the FRS member object

Rename a domain controller using System Properties


You can use this procedure to rename a domain controller by using the System Properties user interface (UI). Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group. To rename a domain controller using System Properties 1. Click Start, and then click Control Panel. 2. In Control Panel, double-click System Properties. 3. On the Computer Name tab, click Change. 4. Click OK to acknowledge that renaming the domain controller may cause it to become temporarily unavailable to users and computers. (See note below.) 5. Under Computer Name, type the new name. 6. Click OK to close the System Properties dialog box. 7. If you are prompted, provide the user name and password for an account with Domain Admin or Enterprise Admin credentials. Note Renaming a domain controller in this way may result in Active Directory replication latency, making it more difficult for clients to locate or authenticate the domain controller under its new name.

See Also
Rename a domain controller using Netdom

Rename a domain controller using Netdom


You can use this procedure to rename a domain controller by using the Netdom commandline tool. The netdom command updates the service principal name (SPN) attributes in Active Directory for the computer account and registers Domain Name System (DNS) resource records for the new computer name. The SPN value of the computer account must be replicated to all domain controllers in the domain, and the DNS resource records for the new computer name must be distributed to all the authoritative DNS servers for the domain name. If the updates and registrations have not occurred prior to removal of the old computer name, some clients might be unable to locate this computer using the new name or the old name. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group. To rename a domain controller using Netdom 1. Open a Command Prompt. 2. Type the following command to add the new domain controller name, and then press ENTER: netdom computername CurrentComputerName /add:NewComputerName 3. Type the following command to designate the new name as the primary computer name, and then press ENTER: netdom computername CurrentComputerName /makeprimary:NewComputerName Term CurrentComputerName Definition The current, or primary, computer name or Internet Protocol (IP) address of the computer that you are renaming.

Term NewComputerName

Definition The new name for the computer. The NewComputerName must be a fully qualified domain name (FQDN). The primary DNS suffix that is specified in the FQDN for NewComputerName must be the same as the primary DNS suffix of CurrentComputerName, or it must match the DNS name of the Active Directory domain that is hosted by this domain controller, or it must be contained in the list of allowed DNS suffixes that is specified in the msDSAllowedDNSSuffixes attribute of the domainDns object.

4. Restart the computer. 5. After the computer restarts, open a Command Prompt. 6. Type the following command to remove the old domain controller name, and then press ENTER: netdom computername NewComputerName /remove:OldComputerName Term NewComputerName OldComputerName Definition The new FQDN that you added for the computer in step 2. The old FQDN of the renamed computer.

See Also
Rename a domain controller using System Properties

Update the FRS member object


Use this procedure to update the File Replication Service (FRS) member object after renaming a domain controller. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group or the Enterprise Admins group. To update the FRS member object 1. Using Ldp.exe (or ADSI edit), find the computer object of the renamed domain controller. 2. Do a recursive search for an object of type nTFRSSubscriber with the computer name of "Domain System Volume (SYSVOL share)" under the Computer object. 3. The search filter is "(&((cn=Domain System Volume (SYSVOL share)) (objectclass=ntfrssubscriber)))". 4. Find the fRSMemberReference attribute of the object returned by the search. 5. Find the object whose domain name is in the fRSMemberReference attribute. This is the Ntfrsmember object corresponding to this domain controller. 6. Change the computer name of this Ntfrsmember object from the old name of the domain controller to the new name of the domain controller.

Decommissioning a Domain Controller


Decommissioning a domain controller effectively removes all Active Directory and related components and returns the domain controller to a member server role. Task Requirements The following tools are required to perform the procedures for this task: Ntdsutil.exe Active Directory Domains and Trusts Active Directory Users and Computers

Active Directory Sites and Services Netdiag.exe Dcdiag.exe

To complete this task, perform the following procedures: 1. View the current operations master role holders To avoid problems, transfer any operations master roles prior to running the Active Directory Installation Wizard to decommission a domain controller so that you can control the 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. Caution During the decommissioning process, the Active Directory Installation Wizard will attempt to transfer any remaining operations master roles to other domain controllers without any user interaction. However, if a failure occurs, the wizard will continue to uninstall Active Directory and leave your domain without roles. Also, 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. 2. Transfer the schema master 3. Transfer the domain naming master 4. Transfer the domain-level operations master roles 5. Determine whether a domain controller is a global catalog server If you remove Active Directory from a domain controller that hosts a 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 log on without an available global catalog server. If you are not sure, do not proceed with removing Active Directory until you know that at least one other global catalog server is available. 6. Verify DNS registration and functionality 7. Verify communication with other domain controllers During the removal of Active Directory, contact with other domain controllers is required to ensure: Any unreplicated changes are replicated to another domain controller.

Removal of the domain controller from the directory. Transfer of any remaining 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 used during the installation of Active Directory. 8. Verify the availability of the operations masters Important If any of the verification tests fail, do not continue until you determine and fix the problems. If these tests fail, the uninstallation is also likely to fail. 9. Uninstall Active Directory 10. Determine whether a Server object has child objects 11. Delete a Server object from a site Note The administrator may not want to remove the Server object if it hosts something in addition to Active DirectoryMicrosoft Exchange, for example.

View the current operations master role holders


Once an operations master role has been transferred, it should be verified that the transfer has occurred successfully throughout the domain. The change must be replicated to all relevant domain members in order to truly take effect. 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. Administrative Credentials To perform this procedure, you must be logged on as a User or an Administrator. To view the current operations master role holder 1. Click Start, click Run, type ntdsutil, and then press ENTER.

2. At the ntdsutil: prompt, type roles and press ENTER. 3. At the fsmo maintenance: prompt, type connections and press ENTER. 4. 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). 5. After receiving confirmation of the connection, type quit and press ENTER to exit this menu. 6. At the fsmo maintenance: prompt, type select operation target and press ENTER. 7. 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 currently assigned to host each role. 8. 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.

Transfer the schema master


Use this procedure to transfer the schema operations master role. The schema master is a forest-wide operations master role. Before you can use the Active Directory Schema snapin for the first time, you must register it with the system. If you have not yet prepared the Active Directory Schema snap-in, see Install the Schema snap-in before you begin this procedure. Note This procedure is performed by using the Microsoft Management Console (MMC), although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, type ? at the Ntdsutil.exe command prompt. Administrative Credentials To perform this procedure, you must be a Schema Administrator in Active Directory.

Transfer the schema master 1. Open the Active Directory Schema snap-in. 2. In the console tree, right-click Active Directory Schema, and click Change Domain Controller. 3. In the Change Domain Controller dialog box, click Specify Name. Then, in the text box, type the name of the server to which you want to transfer the schema master role. Click OK. 4. In the console tree, right-click Active Directory Schema. Click Operations Master. The Change Schema Master box displays the name of the server that is currently holding the role. The targeted domain controller is listed in the second box. 5. Click Change. Click Yes to confirm your choice. The system confirms the operation. Click OK again to confirm that the operation succeeded. 6. Click Close to close the Change Schema Master dialog box. 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.

Transfer the domain naming master


Use this procedure to transfer the domain naming operations master role. The domain naming master is a forest-wide operations master role. Note This procedure is performed by using the Microsoft Management Console (MMC), although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, type ? at the Ntdsutil.exe command prompt. Administrative Credentials To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory.

To transfer the domain naming master 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller. 3. Ensure that the proper domain name is entered in the Domain box. The available domain controllers from this domain are listed. 4. In the Name column, click the domain controller (to select it) to which you want to transfer the role. Click OK. 5. Right-click Active Directory Domains and Trusts, and then click Operations Master. 6. 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. 7. Click Change. To confirm the role transfer, click Yes. Click OK again to close the message box indicating the transfer took place. Click Close to close the Change Operations Master dialog box.

Transfer the domain-level operations master roles


Use this procedure to transfer the three domain-level operations master roles: 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. Note 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory.

To transfer a domain-level operations master role 1. Open Active Directory Users and Computers. 2. At the top of the console tree, right-click Active Directory Users and Computers. Click Connect to Domain Controller. 3. In the list of available domain controllers, click the name of the server to which you want to transfer the role, and then click OK. 4. At the top of the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Masters. The name of the current operations master role holder appears in the Operations master box. The name of the server to which you want to transfer the role appears in the lower box. 5. Click the tab for 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, and then click OK. 6. Repeat steps 4 and 5 for each role that you want to transfer.

Determine whether a domain controller is 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group in Active Directory. To determine whether a domain controller is a global catalog server 1. Open Active Directory Sites and Services. 2. In the console tree, 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. 3. Right-click the NTDS Settings object, and then click Properties.

4. On the General tab, if the Global Catalog box is selected, the domain controller is designated as a global catalog server.

Verify DNS registration and functionality


This procedure verifies that DNS is functioning so that other domain controllers can be located. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory. To verify DNS registration and functionality 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:dns Note For a more detailed response from this command, add /v to the end of the command. 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 with 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 communication with other domain controllers


This procedure verifies that domain controllers can be located. Administrative Credentials

To perform this procedure, you must be a member of the Domain users group in Active Directory. To verify communication with other domain controllers 1. Open a Command Prompt. 2. Type the following command and then press ENTER: netdiag /test:dsgetdc Note For a more detailed response from this command, add /v to the end of the command. 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 the availability of the operations masters


This procedure verifies that the operations masters can be located and that they are online and responding. Administrative Credentials To perform this procedure, you must be a member of the Domain users group in Active Directory. Note You can use these tests prior to installing Active Directory as well as afterward. 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. 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 test. 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 by adding /v to the end of the command to see the detailed response. To verify the availability of the operations masters 1. Open a Command Prompt. 2. Type the following command to ensure that the operations masters can be located and then press ENTER: dcdiag /s: domaincontroller /test:knowsofroleholders /verbose 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 the 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. Press ENTER. 3. Type the following command to ensure that the operations masters are functioning properly and are available on the network: 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. Press ENTER. 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.

Uninstall 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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group.

To uninstall Active Directory 1. Click Start, click Run, type dcpromo and then click OK. 2. The Active Directory Installation Wizard appears. Click Next at the Welcome screen. 3. 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. 4. 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. 5. At the Summary screen, verify that the information is correct and then click Next to proceed with the removal. 6. The wizard proceeds to remove Active Directory. After it finishes, the wizard displays a completion screen. Click Finish to close the wizard. 7. Click Restart to restart the domain controller.

Determine whether a Server object has child objects


After Active Directory is properly installed on a domain controller, the Server object for the domain controller will have a Child NTDS-Settings object. Other applications that are running on domain controllers can also publish Child objects. Prior to deleting a Server object from the Servers container for a site, verify that the Server object has no Child objects. If a Child object appears, do not delete the Server object. Administrative Credentials To perform this procedure, you must be a member of the Domain Users group. To determine whether a server object has child objects 1. Open Active Directory Sites and Services. 2. Expand the Sites container and expand the site of the Server object. 3. Expand the Servers container, and then expand the Server object to view any

Child objects.

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. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To delete a server object from a site 1. Open Active Directory Sites and Services. 2. Expand the Sites container, and then expand the site from which you want to delete a Server object. 3. 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. 4. Click Yes to confirm your choice.

Forcing the Removal of a Domain Controller


Forced removal of a domain controller from Active Directory is intended to be used as a last resort to avoid having to reinstall the operating system on a domain controller that has failed and cannot be recovered. When a domain controller can no longer function in a domain (that is, it is offline), you cannot remove Active Directory in the normal way, which

requires connectivity to the domain. Forced removal is not intended to replace the normal Active Directory removal procedure in any way. It is virtually equivalent to permanently disconnecting the domain controller. Active Directory stores a considerable amount of metadata about a domain controller. During the normal process of uninstalling Active Directory on a domain controller, this metadata is removed from Active Directory through a connection to another domain controller in the domain. A forced removal assumes that there is no connectivity to the domain; therefore, it does not attempt any metadata removal (cleanup). Consequently, forced removal of Active Directory from a domain controller should always be followed by the metadata cleanup procedure, which removes all references to the domain controller from the domain and forest. Forced demotion should not be performed on the last domain controller in a domain. Task Requirements The following tools are required to perform the procedures for this task: Active Directory Sites and Services Dcpromo.exe Ntdsutil.exe

To complete this task, perform the following procedures: 1. Identify replication partners. Connect to one of these domain controllers when you clean up server metadata in procedure 3. 2. Force domain controller removal 3. Clean up server metadata

Identify replication partners


Use this procedure to examine the Connection objects for a domain controller and determine its replication partners. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group in Active Directory.

To identify replication partners 1. Open Active Directory Sites and Services. 2. In the console tree, expand the Sites container to display the list of sites. 3. Double-click the site that contains the domain controller for which you want to determine Connection objects. Note If you do not know the site in which the domain controller is located, 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. 4. Expand the Servers folder to display the list of servers in that site. 5. Expand the name of your domain controller to display its NTDS settings. 6. 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.

Force domain controller removal


Use this procedure to force the removal of Active Directory from a domain controller. Administrative Credentials To perform this procedure, you must be a member of the Domain Admins group. To force domain controller removal 1. Click Start, click Run, type the following command and then press ENTER: Dcpromo /forceremoval 2. At the Welcome to the Active Directory Installation Wizard page, click Next. 3. At the Force the Removal of Active Directory page, click Next. 4. In Administrator Password, type the password and confirmed password that you want to assign to the Administrator account of the local SAM database, and

then click Next. 5. In Summary, click Next.

Clean up server metadata


You perform the metadata cleanup process by using Ntdsutil.exe, a command-line tool that is automatically installed on all domain controllers. Metadata cleanup removes data from Active Directory that identifies a domain controller to the replication system. On a domain controller that is running Windows Server 2003 with Service Pack 1 (SP1), metadata cleanup also removes File replication service (FRS) connections and attempts to transfer or seize any operations master roles that the retired domain controller holds. These additional processes are performed automatically. Administrative credentials To complete this procedure, you must be a member of the Enterprise Admins group. To clean up server metadata 1. Open a command prompt. 2. Type the following command, and then press ENTER: ntdsutil 3. At the ntdsutil: prompt, type: metadata cleanup 4. Perform metadata cleanup as follows: If you are performing metadata cleanup by using the version of Ntdsutil.exe that is included with Windows Server 2003 SP1, at the metadata cleanup: prompt, type: remove selected server ServerName Or remove selected server ServerName1 on ServerName2

Value ServerName, ServerName1

Definition The distinguished name of the domain controller whose metadata you want to remove, in the form cn=ServerName,cn=Servers,cn=SiteName, cn=Sites,cn=Configuration,dc=ForestRootDomain The DNS name of the domain controller to which you want to connect and from which you want to remove server metadata

ServerName2

If you are performing metadata cleanup by using the version of Ntdsutil.exe that is included with Windows Server 2003 with no service pack, perform metadata cleanup as follows: a. At the metadata cleanup: prompt, type: connection b. At the server connections: prompt, type: connect to server Server c. At the server connections: prompt, type:

quit d. At the metadata cleanup: prompt, type: select operation target e. At the select operation target: prompt, type: list sites A numbered list of sites appears. f. At the select operation target: prompt, type:

select site SiteNumber g. At the select operation target: prompt, type: list domains in site A numbered list of domains in the selected site appears. h. At the select operation target: prompt, type: select domain DomainNumber i. At the select operation target: prompt, type:

list servers in site A numbered list of servers in a domain and site appears. j. At the select operation target: prompt, type:

select server ServerNumber k. At the select operation target: prompt, type:

quit l. At the metadata cleanup: prompt, type:

remove selected server Value Server Description The DNS name of a domain controller that you want to connect to The number associated with the site of the server that you want to clean up that appears in the list The number associated with the domain of the server that you want to clean up that appears in the list The number associated with the server that you want to clean up that appears in the list

SiteNumber

DomainNumber

ServerNumber

At this point, Active Directory confirms that the domain controller was removed successfully. If you receive an error message that indicates that the object cannot be found, Active Directory might have already removed the domain controller. 5. At the metadata cleanup: and ntdsutil: prompts, type quit.

Additional Resources for Administering Active Directory


For general information about how Active Directory works and how to deploy, monitor, and delegate Active Directory, see the following resources: Active Directory Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=26094) Designing and Deploying Directory and Security Services on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=27638) "Monitoring Active Directory Health" in the Active Directory Management Pack Technical Reference for MOM 2005 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=43127) Best Practices for Delegating Active Directory Administration on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=46579) For specific information about troubleshooting Active Directory problems, see the following resources: Troubleshooting Active Directory Operations

Identity and Directory Services Community on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=20151) Windows Server Active Directory Newsgroup on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=43065) For development information about Active Directory, see the following resources: Active Directory Platform SDK on the Microsoft Web site (http://go.microsoft.com/fwlink/?linkid=142) Lightweight Directory Access Protocol Platform SDK on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkID=2972) RFC Pages and Internet-Drafts on the Internet Engineering Task Force Web site (http://go.microsoft.com/fwlink/?LinkID=121) Note Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

Troubleshooting Active Directory Operations


This Active Directory Troubleshooting guide provides troubleshooting information for Active Directory in the Microsoft Windows Server 2003 and Windows Server 2003 with Service Pack 1 (SP1) operating systems. In this guide Configuring a Computer for Troubleshooting Active Directory Troubleshooting Active Directory Replication Problems Additional Resources for Troubleshooting Active Directory

This initial release of the Active Directory Troubleshooting guide includes troubleshooting recommendations and procedures for diagnosing and fixing problems that may occur with Active Directory replication. This content focuses primarily on responses to Directory Service event log messages and tool-based error messages that might be reported by the Repadmin.exe and Dcdiag.exe tools, which are available in Windows Support Tools. Installation of Windows Server 2003 with SP1 is encouraged for improved diagnostic support in both Windows Support Tools, which you must install separately, and the Ntdsutil.exe administrative command-line tool, which is included with the operating system. Acknowledgments Key Technical Reviewers: Arren Conner, Gregory Johnson, Rob Kochman, Ajit Krishnan, Dave Tesar

Configuring a Computer for Troubleshooting Active Directory


Before you can use advanced troubleshooting techniques to identify and fix Active Directory problems, you must configure your computer for troubleshooting and have a basic understanding of Windows Server 2003 troubleshooting concepts, procedures, and tools. For information about monitoring tools for Windows Server 2003, see Monitoring and Status Tools on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=59526).

Configuration Tasks for Troubleshooting


To configure your computer for troubleshooting, perform the following tasks: Install Windows Server 2003 SP1 Install Windows Support Tools Install Network Monitor Set logging levels

Install Windows Server 2003 SP1


If possible, upgrade domain controllers to Windows Server 2003 Service Pack 1 (SP1). To install this service pack, go to the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=9999) and follow instructions for downloading the service pack. The advantages of running Windows Server 2003 with SP1 with regard to troubleshooting include enhancements to the Ntdsutil command-line tool. Ntdsutil.exe has new functionality that makes it easier to remove domain controller metadata and to authoritatively restore directory objects.

Install Windows Support Tools


For improved diagnostic support, install Windows Support Tools that ship with Windows Server 2003 SP1. The SP1 version of Windows Support Tools includes enhanced versions of the Dcdiag.exe and Repadmin.exe tools. The Dcdiag.exe command-line tool now provides new reporting on the overall health of replication with respect to Active Directory security, as well as new Domain Name System (DNS) diagnostic tests. You can use Repadmin.exe to manage replication consistency settings on multiple domain controllers instead of editing the registry on individual computers. Make sure that the SP1 version of Windows Support Tools is installed on all domain controllers that are running Windows Server 2003 with SP1.

Options for Running SP1 Windows Support Tools


You can run Windows Support Tools that ship with Windows Server 2003 SP1 on computers running the following operating systems: Windows Server 2003 with SP1 Windows Server 2003 without SP1

You can also run some tools, such as Repadmin.exe and Dcdiag.exe, on computers running Windows XP Professional, Windows XP Professional with SP1, or Windows XP Professional with Service Pack 2 (SP2). Options for other tools vary by tool. In this guide, the operating system that is required for running a tool is specified as a prerequisite for each procedure.

Options for Installing SP1 Windows Support Tools


The SP1 version of Windows Support Tools can be installed as an .msi package only on computers running Windows Server 2003 with SP1. To run Repadmin and Dcdiag from computers running Windows Server 2003 without SP1 or from computers running Windows XP Professional, you must copy the respective executable files to those computers. Requirements Administrative credentials: To complete this procedure, you must be a member of the Builtin Administrators group. Operating system: Windows Server 2003 with SP1. You cannot use suptools.msi to install the SP1 version of Windows Support Tools on a computer that is not running Windows Server 2003 with SP1. To install Windows Support Tools 1. Insert the Windows CD into your CD-ROM drive. 2. If you are prompted to reinstall Windows, click No. 3. When the Welcome screen appears, click Perform additional tasks, and then click Browse this CD. 4. Go to the \Support\Tools folder. For complete setup information, see the Readme.htm file in this folder. 5. Double-click suptools.msi. 6. Follow the instructions that appear on your screen.

Install Network Monitor


Use Network Monitor to troubleshoot connectivity issues by tracing network traffic between computers. For information about installing and using Network Monitor, see Network Monitor on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42987).

Set Logging Levels


If the information that you receive in the Directory Service log in Event Viewer is not sufficient for troubleshooting, raise the logging levels by using the appropriate registry entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. By default, the logging levels for all entries are set to 0, which provides the minimum amount of information. The highest logging level is 5. Increasing the level for an entry causes additional events to be logged in the Directory Service event log. The following diagram shows the diagnostic entries that are available. Directory Service Diagnostic Logging Levels

Use the following procedure to change the logging level for a diagnostic entry. Caution It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console

(MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the domain of the domain controller on which you are setting the logging level. Tools: Regedit.exe

To change the logging level for a diagnostic entry 1. Click Start, click Run, type regedit, and then click OK. 2. Navigate to the entry for which you want to set logging in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnosti cs. 3. Double-click the entry, and for the Base click Decimal. 4. In the Value data box, type an integer from 0 through 5, and then click OK.

Troubleshooting Active Directory Replication Problems


Active Directory replication problems can have several different sources. For example, Domain Name System (DNS) problems, networking issues, or security problems can all cause Active Directory replication to fail. Inbound or outbound replication failure causes Active Directory objects that represent the replication topology, replication schedule, domain controllers, users, computers, passwords, security groups, group memberships, and Group Policy to be inconsistent between domain controllers. Directory inconsistency causes either operational failures or inconsistent results, depending on the domain controller that is contacted for the operation at hand. Active Directory depends on network connectivity, name resolution, authentication and authorization, the directory database, the replication topology, and the replication engine. When the root cause of a replication problem is not immediately obvious, determining the cause among the many possible causes requires systematic elimination of probable causes.

Event and Tool Solution Recommendations


Ideally, the red (Error) and yellow (Warning) events in the Directory Service event log suggest the specific constraint that is causing replication failure on the source or destination domain controller. If the event message suggests steps for a solution, try the steps listed in the event. The Repadmin tool and other diagnostic tools also provide information that can help you resolve replication failures.

Ruling Out the Obvious


Sometimes replication errors occur because of intentional disruptions. For example, when you troubleshoot Active Directory replication problems, rule out intentional disconnections and hardware failures or upgrades first.

Intentional Disconnections
If replication errors are reported by a domain controller that is attempting replication with a domain controller that has been built in a staging site and is currently offline awaiting its deployment in the final production site (remote), you can account for those errors. To avoid separating a domain controller from the replication topology for extended periods, which causes continuous errors until the domain controller is reconnected, consider adding such computers initially as member servers and using the install-from-media method to install Active Directory. You can back up an up-to-date domain controller to removable media (CD/DVD or other media) and ship the media to the destination site. Then, you can use the media to promote the domain controllers at the site, without requiring replication. For more information about installing from media, see Installing a Domain Controller in an Existing Domain Using Restored Backup Media.

Hardware Failures or Upgrades


If replication problems occur as a result of hardware failure (for example, failure of the motherboard, disk subsystem, or hard drive), notify the server owner so that the hardware problem can be resolved. Periodic hardware upgrades can also cause domain controllers to be out of service. Ensure that your server owners have a good system of communicating such outages in advance.

Correct Response to Any Outdated Server Running Windows 2000 Server


If a domain controller running Windows 2000 Server has failed for longer than the number of days in the tombstone lifetime, the solution is always the same: 1. Move the server from the corporate network to a private network. 2. Either forcefully remove Active Directory or reinstall the operating system. 3. Remove the server metadata from Active Directory so that the server object cannot be revived. Note By default, NTDS Settings objects that are deleted are revived automatically for a period of 14 days. Therefore, if you do not remove server metadata (use Ntdsutil to perform metadata cleanup), the server metadata is reinstated in the directory, which prompts replication attempts to occur. In this case, errors will be logged persistently as a result of the inability to replicate with the missing domain controller.

Root Causes
If you rule out intentional disconnections, hardware failures, and outdated Windows 2000 domain controllers, the remainder of replication problems almost always have one of the following root causes: Network connectivity: The network connection might be unavailable or network settings are not configured properly. Name resolution: DNS misconfigurations are a common cause for replication failures. Authentication and authorization: Authentication and authorization problems cause "Access denied" errors when a domain controller tries to connect to its replication partner. Directory database (store): The directory database might not be able to process transactions fast enough to keep up with replication timeouts. Replication engine: If intersite replication schedules are too short, replication queues might be too large to process in the time that is required by the outbound replication schedule. In this case, replication of some changes can be stalled indefinitely potentially, long enough to exceed the tombstone lifetime.

Replication topology: Domain controllers must have intersite links in Active Directory that map to real wide area network (WAN) or virtual private network (VPN) connections. If you create objects in Active Directory for the replication topology that are not supported by the actual site topology of your network, replication that requires the misconfigured topology fails.

General Approach to Fixing Problems


Use the following general approach to fixing replication problems: 1. Monitor replication health daily, or use Repadmin.exe to retrieve replication status daily. 2. Attempt to resolve any reported failure in a timely manner by using the methods described in event messages and this guide. If software might be causing the problem, uninstall the software before you continue with other solutions. 3. If the problem that is causing replication to fail cannot be resolved by any known methods, remove Active Directory from the server and then reinstall Active Directory. For more information about reinstalling Active Directory, see Decommissioning a Domain Controller. 4. If Active Directory cannot be removed normally while connected to the network, use one of the following methods to resolve the problem: Force Active Directory removal in Directory Services Restore Mode, clean up server metadata, and then reinstall Active Directory. Reinstall the operating system, and rebuild the domain controller.

For more information about forcing Active Directory removal, see Forcing the Removal of a Domain Controller.

Monitoring Replication Health


Monitoring for replication failures is critical to being able to solve replication problems quickly and effectively. Use one of the following methods to monitor replication health: Use a monitoring application that you set to capture and report specific errors and events on a daily basis. Use the Repadmin tool to retrieve replication status daily.

Using a Monitoring Application to Monitor Replication Health


For all domain controllers in a forest, monitor replication health on a daily basis by using Microsoft Operations Manager (MOM) or an equivalent monitoring application. For information about using MOM to monitor Active Directory, see Active Directory Management Pack Technical Reference for MOM 2005 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41369).

Using Repadmin to Retrieve Replication Status


Replication status is an important way for you to evaluate the status of the directory service. If replication is working without errors, you know the domain controllers that are online. You also know that the following systems and services are working: DNS infrastructure Kerberos Windows Time service (W32time) Remote procedure call (RPC) Network connectivity

Use Repadmin (Windows Support Tools) to monitor replication status daily by running a command that assesses the replication status of all domain controllers in your forest. The procedure generates a .csv file that you can open in Excel and filter for replication failures. Use the following procedure to retrieve the replication status of all domain controllers in the forest. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or the Enterprise Admins group in the forest. Tools:

Repadmin.exe (Windows Support Tools) Excel (Microsoft Office) To retrieve replication status 1. Open a command prompt, type the following command, and then press ENTER:

repadmin /showrepl * /csv >showrepl.csv 2. In Excel, on the File menu, click Open. 3. In Files of type, click Text Files (*.prn;*.txt;*.csv). 4. In Look in, navigate to showrepl.csv, and then click Open. 5. In the Excel spreadsheet, right-click the column heading for showrepl_COLUMNS (column A) and then click Hide. Repeat for the column labeled Transport Type. 6. Select the row just under the column headings, and then, on the Window menu, click Freeze Pane. 7. Click the upper-left corner of the spreadsheet to highlight the entire spreadsheet. On the Data menu, point to Filter, and then click AutoFilter. 8. In the heading of the Last Success column, click the down arrow, and then click Sort Ascending. 9. In the heading of the Source DC column, click the down arrow, and then click Custom. In the Custom AutoFilter dialog box, complete the custom filter as follows: a. Under Source DC, click does not contain. b. In the corresponding text box, type del to filter deleted domain controllers from the spreadsheet. 10. In the heading of the Last Failure column, click the down arrow, and then click Custom. In the Custom AutoFilter dialog box, complete the custom filter as follows: a. Under Last Failure, click does not equal. b. In the corresponding text box, type 0 to filter for only domain controllers that are experiencing failures. For every domain controller in the forest, the spreadsheet shows the source replication partner, the time that replication last occurred, and the time that the last replication failure occurred for each naming context (directory partition). By using Autofilter in Excel, you can view the replication health for working domain controllers only, failing domain controllers only, or domain controllers that are the least or most current, and you can see the replication partners that are replicating successfully.

Attempting to Resolve Problems


Replication problems are reported in event messages and in various error messages that occur when an application or service attempts an operation. Ideally, these messages are collected by your monitoring application or when you retrieve replication status. Most replication problems are identified in the event messages that are logged in the Directory Service event log. Replication problems might also be identified in the form of error messages in the output of the repadmin /showrepl command.

repadmin /showrepl Error Messages That Indicate Replication Problems


To identify Active Directory replication problems, use the repadmin /showrepl command as described in the previous section. The following table shows error messages that are generated by this command, along with the root causes of the errors and links to topics that provide solutions for the errors. repadmin /showrepl Error Messages Repadmin error The time since last replication with this server has exceeded the tombstone lifetime. Root cause Solution

A domain controller has failed Event ID 2042: It has been inbound replication with the too long since this machine named source domain replicated controller long enough for a deletion to have been tombstoned, replicated, and garbage-collected from Active Directory. If no items appear in the Fixing Replication Inbound Neighbors section Connectivity Problems of the output that is (Event ID 1925) generated by repadmin /showrepl, the domain controller was not able to establish replication links with another domain controller.

No inbound neighbors.

Repadmin error Access is denied.

Root cause

Solution

A replication link exists Fixing Replication Security between two domain Problems controllers, but replication cannot be performed properly due to an authentication failure. This problem can be related to connectivity, DNS, or authentication issues. If this is a DNS error, the local domain controller could not resolve the globally unique identifier (GUID)based DNS name of its replication partner. Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) Fixing Replication Security Problems Fixing Replication Connectivity Problems (Event ID 1925) Fixing Replication Security Problems

Last attempt at <date - time> failed with the Target account name is incorrect.

LDAP Error 49.

The domain controller computer account might not be synchronized with the Key Distribution Center (KDC). The administration tool could not contact Active Directory. The progress of inbound replication was interrupted by a higher priority replication request, such as a request generated manually with the repadmin /sync command. The domain controller posted a replication request and is waiting for an answer. Replication is in progress from this source.

Cannot open LDAP connection to local host Active Directory replication has been preempted.

Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) Wait for replication to complete. This informational message indicates normal operation.

Replication posted, waiting.

Wait for replication to complete. This informational message indicates normal operation.

Event Messages That Indicate Active Directory Replication Problems


The following table lists common events that might indicate problems with Active Directory replication, along with root causes of the problems and links to topics that provide solutions for the problems. Events That Indicate Active Directory Replication Problems Event ID and source 1311 NTDS KCC Root cause Solution

The replication Fixing Replication Topology Problems (Event ID configuration 1311) information in Active Directory does not accurately reflect the physical topology of the network. Strict replication Fixing Replication Lingering Object Problems consistency is not in (Event IDs 1388, 1988, 2042) effect, and a lingering object has been replicated to the domain controller. The attempt to establish a replication link for a writable directory partition failed. This event can have different causes, depending on the error. Fixing Replication Connectivity Problems (Event ID 1925) Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)

1388 NTDS Replication

1925 NTDS KCC

Event ID and source 1988 NTDS Replication

Root cause The local domain controller has attempted to replicate an object from a source domain controller that is not present on the local domain controller because it may have been deleted and already garbage-collected. Replication will not proceed for this directory partition with this partner until the situation is resolved. Replication has not occurred with this partner for a tombstone lifetime, and replication cannot proceed. Active Directory could not resolve the DNS host name of the source domain controller to an Internet Protocol (IP) address, and replication failed.

Solution Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)

2042 NTDS Replication

Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)

2087 NTDS Replication

Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)

Event ID and source 2088 NTDS Replication

Root cause Active Directory could not resolve the DNS host name of the source domain controller to an IP address, but replication succeeded. Update sequence number (USN) rollback has occurred and replication has been stopped. This error indicates an improper Active Directory restore, possibly of a virtual machine file (.vhd).

Solution Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)

2095 NTDS Replication

For an explanation of this problem and recommendations for solutions, see Running Domain Controllers in Virtual Server 2005 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=38330).

5805 Net Logon

A machine account Fixing Replication Security Problems failed to authenticate, which is usually caused by either multiple instances of the same computer name or the computer name not replicating to every domain controller.

For more information about replication concepts, see Active Directory Replication Technologies in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41950). In this section Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)

Fixing Replication Security Problems Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) Fixing Replication Connectivity Problems (Event ID 1925) Fixing Replication Topology Problems (Event ID 1311)

Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
If a domain controller does not replicate for a period of time that is longer than the tombstone lifetime and the domain controller is then reconnected to the replication topology, objects that were deleted from Active Directory while the domain controller was offline can remain on the domain controller as lingering objects.

Tombstone Lifetime and Replication of Deletions


When an object is deleted, Active Directory replicates the deletion as a tombstone object, which consists of a small subset of the attributes of the deleted object. By inboundreplicating this object, other domain controllers in the domain and forest become aware of the deletion. The tombstone is retained in Active Directory for a specified period called the tombstone lifetime. At the end of the tombstone lifetime, the tombstone is deleted from the directory permanently. The default value of the tombstone lifetime depends on the version of the operating system that is running on the first domain controller that is installed in a forest, as follows: Windows 2000 Server or Windows Server 2003: The default value is 60 days. Windows Server 2003 with Service Pack 1 (SP1): The default value is 180 days.

Note The tombstone lifetime value that is in effect when a domain controller is upgraded to Windows Server 2003 SP1 is not changed by upgrading. The existing value is maintained until you change it manually. After the tombstone is removed permanently, the object deletion can no longer be replicated. Therefore, the tombstone lifetime defines how long domain controllers in the forest retain knowledge of a deleted object and thus the time during which a unique

deletion must be received by all direct and transitive replication partners of the originating domain controller.

How Lingering Objects Occur


When conditions beyond your control cause a domain controller to be disconnected for a period that is longer than the tombstone lifetime, one or more objects that are deleted from Active Directory on all other domain controllers might remain on the disconnected domain controller. Such objects are called lingering objects. Because the domain controller is offline during the entire time that the tombstone is alive, the domain controller never receives replication of the tombstone. When it is reconnected to the replication topology, this domain controller acts as a source replication partner that has an object that its destination partner does not have. Replication problems occur when the object on the source domain controller is updated. In this case, when the destination attempts to inbound-replicate the update, the destination domain controller responds in one of two ways: If the destination domain controller has strict replication consistency enabled, it recognizes that it cannot update the object and locally halts inbound replication of the directory partition from that source domain controller. If the destination domain controller has strict replication consistency disabled, it requests the full replica of the updated object. In this case, the object is reintroduced into the directory. Lingering objects can reside in writable or read-only partitions that are potentially replicated between domain controllers in the same or different domains in the same forest.

Causes of Long Disconnections


Unexpectedly long disconnections can be caused by the following conditions: A domain controller is left in a storage room and forgotten, or shipment of a prestaged domain controller to its remote location takes longer than a tombstone lifetime. Replication fails and monitoring is not in place. Failures can occur as follows: A domain controller is started and connected to the corporate intranet but experiences inbound replication failure as a result of an underlying network connectivity failure, name resolution failure, or authentication failure that prevents replication from occurring.

A bridgehead server is overloaded, and replication becomes backlogged. Excessively high replication load on a global catalog server, in combination with a short intersite replication interval, can result in updates not being replicated. Note 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 as a result of 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. Wide area network (WAN) connections are unavailable for long periods. For example, a domain controller onboard a cruise ship might be unable to replicate because the ship is at sea for longer than the tombstone lifetime. The reported event is a false positive because an administrator shortened the tombstone lifetime to force tombstone deletion (garbage collection). The reported event is a false positive because the system clock on the source or destination domain controller is improperly rolled forward or back in time. Clock skews are most common following a system reboot and can have the following causes: System clock battery or motherboard problems.

The time source for a computer is improperly configured, including a time source server configured with Windows Time service (W32time), third-party time servers, and network routers. The system clock is advanced or rolled back by an administrator attempting to extend the useful life of a system state backup or accelerate the garbage collection of deleted objects. Make sure that the system clock reflects the actual time and that event logs do not contain events from the future or invalid past.

Indications That a Domain Controller Has Lingering Objects


An outdated domain controller can store lingering objects with no noticeable effect as long as an administrator, application, or service does not update the lingering object or attempt

to create an object with the same name in the domain or with the same user principal name (UPN) in the forest. However, the existence of lingering objects can cause problems, especially if the object is a security principal.

Symptoms Associated with Lingering Objects


The following symptoms indicate that a domain controller has lingering objects: A deleted user or group account remains in the global address list (GAL) on Exchange servers. Therefore, although the account name appears in the GAL, attempts to send e-mail messages result in errors. Multiple copies of an object appear in the object picker or GAL for an object that should be unique in the forest. Duplicate objects sometimes appear with altered names, causing confusion on directory searches. For example, if the relative distinguished name of two objects cannot be resolved, conflict resolution appends "*CNF:GUID" to the name, where * represents a reserved character, CNF is a constant that indicates a conflict resolution, and GUID represents the objectGUID attribute value. E-mail messages are not delivered to a user whose Active Directory account appears to be current. After an outdated domain controller or global catalog server becomes reconnected, both instances of the user object appear in the global catalog. Because both objects have the same e-mail address, e-mail messages cannot be delivered. A universal group that no longer exists continues to appear in a users 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, but you do not see the object in Active Directory. An error message reports that the object already exists. Searches that use attributes of an existing object incorrectly find multiple copies of an object of the same name. One object has been deleted from the domain, but it remains in an isolated global catalog server. If an attempt is made to update a lingering object that resides in a writable directory partition, events are logged on the destination domain controller. However, if the only version of a lingering object exists in a read-only directory partition on a global catalog server, the object cannot be updated and this type of event will never be triggered.

Registry Setting That Determines Whether Lingering Objects Are Replicated


If a writable lingering object exists in your environment and an attempt is made to update the object, the value in the strict replication consistency registry entry (type REG_DWORD) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters determines whether replication proceeds or is stopped, as follows: 1 (enabled): Inbound replication of the specified directory partition from the source is stopped on the destination. 0 (disabled): The destination requests the full object from the source domain controller, and the lingering object is revived in the directory as a new object.

Default Settings for Strict Replication Consistency


The default value for the strict replication consistency registry entry is determined by the conditions under which the domain controller was installed into the forest. Note Raising the domain or forest functional level does not change the replication consistency setting on any domain controller. Strict replication consistency enabled The value of strict replication consistency on domain controllers that are installed into a forest defaults to enabled (1) under the following conditions: The forest root domain of a new forest is created by upgrading the Windows NT 4.0 primary domain controller (PDC) to Windows Server 2003 by using the Windows Server 2003 version of Winnt32.exe. The forest root domain of a new forest is created by installing Active Directory on a server running Windows Server 2003. Strict replication consistency disabled The value of strict replication consistency on domain controllers defaults to disabled (0) under the following conditions: A domain controller running Windows 2000 Server is upgraded to Windows Server 2003. A server running Windows 2000 Server is promoted into a Windows Server 2003 forest.

If you have a domain controller that is running Windows Server 2003 with SP1, you do not need to edit the registry to set strict replication consistency. Instead, you can use Repadmin to set the value for one or all domain controllers in the forest. To set strict replication consistency for specific domain controllers or for all domain controllers, see Event ID 1388 or 1988: A lingering object is detected. For more information about strict replication consistency, see "How the Active Directory Replication Model Works" in the Windows Server 2003 Technical Reference on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=27636.

Tool for Removing Lingering Objects


On domain controllers running Windows Server 2003 or Windows Server 2003 with SP1, use Repadmin.exe (in Windows Support Tools) to remove the lingering object or objects. Windows Support Tools are available on the operating system CD in the Support\Tools folder. The version of Repadmin that ships with Windows Server 2003 provides the option /removelingeringobjects, which safely removes instances of lingering objects from both writable directory partitions and read-only directory partitions. The repadmin /removelingeringobjects command does the following: 1. Compares the directory database objects on a reference domain controller with the objects on the target domain controller, which contains (or is suspected to contain) lingering objects. 2. Either removes the lingering objects or logs the potential deletions to the Directory Service event log, as follows: If you use the /advisory_mode parameter, events are logged in the Directory Service event log for the objects that are found. If you do not use the /advisory_mode parameter, the found objects are deleted without replicating the deletions; that is, the deletions occur only on the target domain controller. Choose the problem that best describes your situation from the following list, and then step through the suggested fix: Event ID 1388 or 1988: A lingering object is detected

A deleted account remains in the Address Book, e-mail is not received, or a duplicate account exists Event ID 2042: It has been too long since this machine replicated

See Also
Configuring a Computer for Troubleshooting Active Directory

Event ID 1388 or 1988: A lingering object is detected


If a destination domain controller logs event ID 1388 or event ID 1988, a lingering object has been detected and one of two conditions exists on the destination domain controller: Event ID 1388: Inbound replication of the lingering object has occurred on the destination domain controller. Event ID 1988: Inbound replication of the directory partition of the lingering object has been blocked on the destination domain controller.

Event ID 1388
This event indicates that a destination domain controller that does not have strict replication consistency enabled has received a request to update an object that does not reside in the local copy of the Active Directory database. In response, the destination domain controller has requested the full object from the source replication partner. In this way, a lingering object has been replicated ("reanimated") to the destination domain controller. Important When event ID 1388 occurs, if either the source domain controller (the replication partner that is outbound-replicating the lingering object) or the destination domain controller (the inbound replication partner that reports event ID 1388) is running Windows 2000 Server, you cannot use the Repadmin tool to remove lingering objects. For information about how to remove lingering objects in this case, see article 314282, "Lingering objects may remain after you bring an out-of-date global catalog server back online," on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=41410. The procedures and information in this article apply to the removal of lingering objects from global catalog servers as well as from domain controllers that are not global catalog servers. The event text identifies the source domain controller and the outdated (lingering) object. An example version of the event text is as follows:
Event Type:Error

Event Source:NTDS Replication Event Category:Replication Event ID:1388 Date:2/21/2005 Time:9:19:48 AM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: Another domain controller (DC) has attempted to replicate into this DC an object which is not present in the local Active Directory database. The object may have been deleted and already garbage collected (a tombstone lifetime or more has past since the object was deleted) on this DC. The attribute set included in the update request is not sufficient to create the object. The object will be re-requested with a full attribute set and re-created on this DC. Source DC (Transport-specific network address): 4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com Object: CN=InternalApps,CN=Users,DC=contoso,DC=com Object GUID: a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a Directory partition: DC=contoso,DC=com Destination highest property USN: 20510 User Action: Verify the continued desire for the existence of this object. To discontinue re-creation of future similar objects, the following registry key should be created. Registry Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency

Event ID 1988
This event indicates that a destination domain controller that has strict replication consistency enabled has received a request to update an object that does not exist in its local copy of the Active Directory database. In response, the destination domain controller has blocked replication of the directory partition containing that object from that source domain controller. The event text identifies the source domain controller and the outdated (lingering) object. An example version of the event text is as follows:
Event Event Event Event Type:Error Source:NTDS Replication Category:Replication ID:1988

Date:2/21/2005 Time:9:13:44 AM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: Active Directory Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory database. Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed. Objects that have been deleted and garbage collected from an Active Directory partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as "lingering objects". This event is being logged because the source DC contains a lingering object which does not exist on the local DCs Active Directory database. This replication attempt has been blocked. The best solution to this problem is to identify and remove all lingering objects in the forest. Source DC (Transport-specific network address): 4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com Object: CN=InternalApps,CN=Users,DC=contoso,DC=com Object GUID: a21aa6d9-7e8a-4a8f-bebf-c3e38d0b733a

Cause
An object that has been permanently deleted from Active Directory (that is, its tombstone has been garbage-collected) remains on a domain controller. The domain controller failed to receive direct or transitive replication of the object deletion because it was disconnected (offline or experiencing an inbound replication failure) from the replication topology for a period that exceeded a tombstone lifetime. That object has been updated on the domain controller, causing a replication notification to the replication partner that an update is ready for replication. The replication partner has responded according to its replication consistency setting. This notification applies to attempted replication of a writable object. A copy of the writable lingering object might also exist on a global catalog server.

Solution
If replication of a lingering object has been detected, you can remove the object from Active Directory, along with any read-only replicas of the object, by identifying the domain

controllers that might store this object (including global catalog servers) and running a repadmin command to remove lingering objects against these servers (repadmin /removelingeringobjects). This command is available on domain controllers that are running the version of Repadmin.exe that is included with Windows Support Tools in Windows Server 2003. If the lingering object is present in a writable or read-only directory partition on a domain controller running Windows Server 2003 or Windows Server 2003 with Service Pack 1 (SP1), you can remove lingering objects by running the repadmin /removelingeringobjects command against that target domain controller. To remove lingering objects, do the following: 1. Use the event text to identify the following: a. Directory partition of the object b. Source domain controller that attempted replication of the lingering object 2. Install Windows Support Tools on the domain controller that received the event, if necessary. See "Install Windows Support Tools" in Configuring a Computer for Troubleshooting Active Directory. 3. Use Repadmin to Identify the GUID of an Authoritative Domain Controller 4. Use Repadmin to Remove Lingering Objects 5. Enable Strict Replication Consistency, if necessary.

Use Repadmin to Identify the GUID of an Authoritative Domain Controller


To perform the procedure that removes lingering objects, you must identify the globally unique identifier (GUID) of an up-to-date domain controller that has a writable replica of the directory partition that contains the lingering object that has been reported. The directory partition is identified in the event message. The object GUID of a domain controller is stored in the objectGUID attribute of the NTDS Settings object. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the domain of ServerName. Tool: Repadmin.exe (Windows Support Tools)

To identify the GUID of a domain controller 1. At a command prompt, type the following command, and then press ENTER: repadmin /showrepl ServerName where ServerName is the name of the domain controller for which you want to display the GUID. 2. In the first section of the output, locate the objectGuid entry. Select and copy the GUID value into a text file so that you can use it elsewhere.

Use Repadmin to Remove Lingering Objects


If the destination domain controller and source domain controller are both running Windows Server 2003, you can remove lingering objects by using Repadmin. If either domain controller is running Windows 2000 Server, follow instructions in the article 314282, "Lingering objects may remain after you bring an out-of-date global catalog server back online," on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=41410. Requirements Operating system: Windows Server 2003 for ServerName and ServerGUID Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the DirectoryPartition domain. Tool: Repadmin.exe (Windows Support Tools) To use Repadmin to remove lingering objects 1. At a command prompt, type the following command, and then press ENTER: repadmin /removelingeringobjects ServerName ServerGUID DirectoryPartition /advisory_mode Term ServerName Definition The name of the domain controller that has lingering objects, as identified in the event message (event ID 1388 or event ID 1988). You can use the Domain Name System (DNS) name or the distinguished name. The GUID of a domain controller that has an up-to-date writable replica of the directory partition that contains the lingering object

ServerGUID

Term DirectoryPartition

Definition The distinguished name of the directory partition that is identified in the event message. For example, DC=RegionalDomainName,DC=ForestRootDomainName,DC=com for a domain directory partition, CN=configuration,DC=ForestRootDomainName,DC=com for the configuration directory partition, or CN=schema,CN=configuration,DC=ForestRootDomainName,DC=com for the schema directory partition

/advisory_mode logs the lingering objects that will be removed so that you can review them, but it does not remove them. 2. Repeat step 1 without /advisory_mode to delete the identified lingering objects from the directory partition. 3. Repeat steps 1 and 2 for every domain controller that might have lingering objects. Note The ServerName parameter uses the DC_LIST syntax for repadmin, which allows the use of * for all domain controllers in the forest and gc: for all global catalog servers in the forest. To see the DC_LIST syntax, type repadmin /listhelp.

Enable Strict Replication Consistency


To ensure that lingering objects cannot be replicated if they occur, enable strict replication consistency on all domain controllers. The setting for replication consistency is stored in the registry on each domain controller. However, on domain controllers that are running Windows Server 2003 with SP1, you can use Repadmin to enable strict replication consistency on one or all domain controllers. On domain controllers running Windows Server 2003, Windows 2000 Server with Service Pack 3 (SP3), or Windows 2000 Server with Service Pack 4 (SP4), you must edit the registry to enable the setting.

Use Repadmin to Enable Strict Replication Consistency


Requirements: Operating system: Windows Server 2003 with SP1 Administrative credentials:

To complete this procedure on a single domain controller, you must be a member of the Domain Admins group. To complete this procedure on all domain controllers in the forest, you must be a member of the Enterprise Admins group in the forest. Tool: Repadmin.exe (Windows Support Tools that are included with Windows Server 2003 SP1) To use Repadmin to enable strict replication consistency 1. Open a command prompt, type the following command, and then press ENTER: repadmin /regkey DC_LIST +strict where DC_LIST is the name of a single domain controller. (* applies the change to all domain controllers in the forest.) For the domain controller name, you can use the Domain Name System (DNS) name, the distinguished name of the domain controller computer object, or the distinguished name of the domain controller server object. 2. If you do not use * to apply the change to all domain controllers, repeat step 1 for every domain controller on which you want to enable strict replication consistency. Note For more naming options and information about the syntax of the DC_LIST parameter, at the command prompt, type repadmin /listhelp.

Edit the Registry to Enable Strict Replication Consistency


On a domain controller that is running Windows Server 2003 without a service pack, edit the registry to enable strict replication consistency. The setting for replication consistency is stored in the Strict Replication Consistency entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Values are as follows: Value: 1 (0 to disable) Default: 1 (enabled) in a new Windows Server 2003 forest; otherwise 0. Data type: REG_DWORD

Requirements:

Operating system: Windows Server 2003, Windows 2000 Server with SP3, Windows 2000 Server with SP4 Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group. Tool: Registry editor (for example, Regedit.exe) Caution It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution. To edit the registry to enable strict replication consistency 1. Open a registry editor. 2. Navigate to Strict Replication Consistency entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Paramete rs. 3. Set the value in the Strict Replication Consistency entry to 1.

A deleted account remains in the Address Book, e-mail is not received, or a duplicate account exists
Deleted accounts remaining in the global address list (GAL), e-mail messages for existing accounts not being received, or duplicate objects existing in Active Directory are all symptoms that can indicate a lingering object problem. If you have no error or event that identifies the lingering object and its directory partition (for example, event ID 1388 or event ID 1988), you must search the global catalog for an object that you believe might be causing the problem. When you identify the lingering object and the directory partition of the object, you can perform the procedures to remove it.

Solution
Based on these symptoms of a lingering object, you usually have a good idea of the name of the object and you can use the following steps to solve the problem: Use this name to identify the object in the global catalog. Identify the directory partition of the object.

Remove all lingering objects from that directory partition on all global catalog servers in the forest.

Identify the Duplicate (Lingering) Object


Use the following procedure to identify the duplicate (lingering) object by searching the global catalog for its distinguished name. Use an attribute that uniquely identifies the object for the account that is not receiving e-mail, cannot be created because it already exists, or appears in the Address Book or in access control lists (ACLs) when it has already been deleted. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Users group. Tool: Ldp.exe (Windows Support Tools)

To establish the distinguished name of an object 1. Click Start, click Run, type Ldp, and then click OK. 2. On the Connection menu, click Connect. 3. In Port, type 3268, and then click OK. 4. On the Connection menu, click Bind. 5. In the Bind dialog box, provide credentials for a user account in the forest, and then click OK. 6. On the View menu, click Tree. 7. In the Tree View dialog box, in BaseDN, type the distinguished name of the forest root domain, and then click OK. 8. In the console tree, right-click the forest root domain, and then click Search. 9. In the Search dialog box, in Filter, replace the default filter (objectClass=*) to create a filter of the following form:

(attribute=value) where attribute is the Lightweight Directory Access Protocol (LDAP) name of an attribute and value is the value that you know or suspect to be associated with the object that you are searching for. For example, use (userPrincipalName=JanD@contoso.com), (sAMAccountName=JanD), or (sn=Dryml) to locate the duplicate user object Jan Dryml. You can use the asterisk (*) in the value field if you want to search all objects. 10. In the Scope box, click Subtree, and then click Run. 11. Click Close, and then view the results. You must identify which of the displayed objects should be removed from Active Directory. An indication that you have found a lingering object that exists only on a global catalog server is that the object does not exist in a writable replica of the directory partition. 12. If necessary, repeat steps 8 through 10 to rephrase the query, and then run it again.

Identify the Directory Partition of the Object


After you identify the distinguished name of the object that is causing problems, if it is a domain object, identify the domain in which it is located by looking at the DC= part of the distinguished name. For example, if the object you find has the distinguished name CN=Jan Dryml,CN=Users,DC=Region1,DC=Contoso,DC=com, the directory partition name for the user account is DC=Region1,DC=Contoso,DC=com.

Remove the Lingering Object


Use the directory partition name in the procedure "To use Repadmin to remove lingering objects" to remove the lingering object from all domain controllers and global catalog servers in the forest as described in "Event ID 1388 or 1988: A lingering object is detected."

Event ID 2042: It has been too long since this machine replicated
If a domain controller has not replicated with its partner for longer than a tombstone lifetime, it is possible that a lingering object problem exists on one or both domain controllers. When this condition occurs, inbound replication with the source partner is stopped on the destination domain controller and event ID 2042 is logged in the Directory

Services event log. The event identifies the source domain controller and the appropriate steps to take to either remove the outdated domain controller or remove lingering objects and restore replication from the source domain controller. An example of the event text is as follows:
Event Type:Error Event Source:NTDS Replication Event Category:Replication Event ID:2042 Date:3/22/2005 Time:7:28:49 AM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. Replication has been stopped with this source. The reason that replication is not allowed to continue is that the two machine's views of deleted objects may now be different. The source machine may still have copies of objects that have been deleted (and garbage collected) on this machine. If they were allowed to replicate, the source machine might return objects which have already been deleted. Time of last successful replication: 2005-01-21 07:16:03 Invocation ID of source: 0397f6c8-f6b8-0397-0100-000000000000 Name of source: 4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com Tombstone lifetime (days): 60 The replication operation has failed. User Action: Determine which of the two machines was disconnected from the forest and is now out of date. You have three options: 1. Demote or reinstall the machine(s) that were disconnected. 2. Use the "repadmin /removelingeringobjects" tool to remove inconsistent deleted objects and then resume replication. 3. Resume replication. Inconsistent deleted objects may be introduced. You can continue replication by using the following registry key. Once the systems replicate once, it is recommended that you remove the key to reinstate the protection. Registry Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner

The repadmin /showrepl command also reports error 8416:


Source: Default-First-Site-Name\DC1 ******* 1502 CONSECUTIVE FAILURES since 2005-01-21 07:16:00 Last error: 8614 (0x21a6): The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

Solution
Treat this occurrence as a lingering object condition, and do the following: Run the repadmin /showrepl command on the domain controller that received the error to determine which domain controller has been disconnected for longer than a tombstone lifetime. Remove lingering objects. Follow the instructions for removing lingering objects from the source and destination domain controllers as described in Event ID 1388 or 1988: A lingering object is detected. Restart replication on the destination domain controller. After you remove lingering objects, you must restart replication on the domain controller that logged the event by editing the registry setting that allows replication with a potentially out-of-date domain controller. You can also perform this procedure if you do not want to wait to remove lingering objects and you want to start replication immediately. Reset the registry to protect the domain controller against outdated replication. After replication has resumed on the domain controller that logged the event, reset the registry so that this domain controller continues to log events if replication is attempted with a domain controller where the last successful replication occurred longer than a tombstone lifetime ago.

Restart Replication Following Event ID 2042


To restart inbound replication on the destination domain controller following event ID 2042, you must edit the Allow Replication With Divergent and Corrupt Partner registry entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Use the following procedure to change the registry entry value. This procedure does not require a restart of the domain controller to take effect.

Caution It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the domain of the domain controller. Tool: Regedit.exe

To restart replication following event ID 2042 1. Click Start, click Run, type regedit, and then click OK. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Paramet ers 3. In the details pane, create or edit the registry entry as follows: If the registry entry exists in the details pane, modify the entry as follows: a. In the details pane, right-click Allow Replication With Divergent and Corrupt Partner, and then click Modify. b. In the Value data box, type 1, and then click OK. If the registry entry does not exist, create the entry as follows: a. Right-click Parameters, click New, and then click DWORD Value. b. Type the name Allow Replication With Divergent and Corrupt Partner, and then press ENTER. c. Double-click the entry. In the Value data box, type 1, and then click OK.

Reset the Registry to Protect Against Outdated Replication


When you are satisfied that lingering objects have been removed and replication has occurred successfully from the source domain controller, edit the registry to return the value in Allow Replication With Divergent and Corrupt Partner to 0.

Note If you did not remove the lingering objects, attempting replication might result in replication of a lingering object. If strict replication consistency is enabled on the destination domain controller, replication with the source domain controller will be blocked again.

Fixing Replication Security Problems


When security problems cause replication to fail, various event log messages and Repadmin messages contain error codes that identify the problems. The version of Dcdiag.exe that is included with Windows Support Tools in Windows Server 2003 Service Pack 1 (SP1) provides new functionality that reports on the overall health of replication with respect to Active Directory. Dcdiag is modified to detect common causes of "Access denied" events, "Account unknown" events, and similar events. The error codes that Dcdiag detects are described in the following table. Error codes that are marked with an asterisk (*) are not always caused by a security problem. Error code 5 1314* 1326 1396 1908 1397* Description Access is denied. A required privilege is not held by the client. Logon failure: unknown user name or bad password. Logon failure: The target account name is incorrect. Could not find the domain controller for this domain. Mutual authentication failed. The server's password is out of date at the domain controller. There is a time and/or date difference between the client and server. The remote procedure call (RPC) server is unavailable.

1398* 1722*

Error code 2202* 8453

Description The specified username is invalid. Replication access was denied.

Use the procedures in An "Access denied" or other security error has caused replication problems to diagnose and fix replication security problems.

An "Access denied" or other security error has caused replication problems


Replication problems that have security causes can be tested and diagnosed by using the version of Dcdiag.exe that is included with Windows Support Tools in Windows Server 2003 Service Pack 1 (SP1).

Cause
A replication destination domain controller cannot contact its source replication partner to get Active Directory updates as a result of one or more security errors occurring on the connection between the two domain controllers.

Solution
Run the replication security error diagnostic test that is available in the version of Dcdiag in Windows Support Tools that is included in Windows Server 2003 SP1.

Test a Domain Controller for Replication Security Errors


You can test any or all domain controllers in your forest for security errors. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group to test a domain controller in your domain or a member of the Enterprise Admins group to test a domain controller in another domain. Tool: Dcdiag.exe (Windows Support Tools) in Windows Server 2003 SP1 Operating system:

Although you can run the enhanced version of Dcdiag on computers running Windows XP Professional and Windows Server 2003 with no service pack installed, to run the new replication security test (/test:CheckSecurityError), you must run Dcdiag on a domain controller running Windows Server 2003 with SP1. You can run the new Dcdiag replication security tests against domain controllers that are running the following operating systems: Windows 2000 Server with Service Pack 3 (SP3) Windows 2000 Server with Service Pack 4 (SP4) Windows Server 2003 Windows Server 2003 with SP1 To test a domain controller for replication security errors 1. At a command prompt, type the following command, and then press ENTER: dcdiag /test:CheckSecurityError /s:DomainControllerName where DomainControllerName is the Domain Name System (DNS) name, network basic input/output system (NetBIOS) name, or distinguished name of the domain controller on which you want to test. If you do not use the /s: switch, the test is run against the local domain controller. You can also test all domain controllers in the forest by using /e: instead of /s:. 2. Copy the report into Notepad or an equivalent text editor 3. Scroll to the Summary table near the bottom of the Dcdiag log file. 4. Note the names of all domain controllers that reported Warn or Fail status in the Summary table. 5. Find the detailed breakout section for the problem domain controller by searching on the string DC: DomainControllerName. 6. Make the required configuration changes on the domain controllers. Rerun Dcdiag /test:CheckSecurityError with the /e: or /s: switch to validate the configuration changes.

Test the Connection Between Two Domain Controllers for Replication Security Errors
You can test the connection between two domain controllers in your forest for replication security errors. The domain controller that represents the source of the inbound connection

does not have to be an existing source to run this test; that is, a connection object from that domain controller does not have to exist on the destination domain controller. The test is useful in the following scenarios: A connection exists between a source and a destination, and you receive a security error. A connection should be created automatically by the Knowledge Consistency Checker (KCC) and you want to test why the connection does not exist. You are trying to create a connection between two domain controllers and you receive a security error. You want to determine whether a connection could be created if you wanted to add one on this destination from the specified source. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group to test the connection between domain controllers in your domain or a member of the Enterprise Admins group to test the connection between domain controllers in different domains. Tool: Dcdiag.exe (Windows Support Tools) included in Windows Server 2003 SP1 Operating system: Although you can run the enhanced version of Dcdiag on computers that are running Windows XP Professional and Windows Server 2003 with no service pack installed, to run the new replication security test (/test:CheckSecurityError), you must run Dcdiag on a domain controller running Windows Server 2003 with SP1. You can run the new Dcdiag replication security tests against domain controllers running the following operating systems: Windows 2000 Server with SP3 Windows 2000 Server with SP4 Windows Server 2003 Windows Server 2003 with SP1 To test the connection between two domain controllers for replication security errors 1. At a command prompt, type the following command, and then press ENTER: dcdiag /test:CheckSecurityError /ReplSource:SourceDomainControllerName

where SourceDomainControllerName is the DNS name, NetBIOS name, or distinguished name of the real or potential "from" server that is represented by a real or potential connection object that you want to test. This command tests the connection between the domain controller on which you run the command and the source domain controller. 2. Copy the report into Notepad or an equivalent text editor. 3. Scroll to the Summary table near the bottom of the Dcdiag log file. 4. Note the names of all domain controllers that reported Warn or Fail status in the Summary table 5. Find the detailed breakout section for the problem domain controller by searching on the string DC: DomainControllerName. 6. Make the required configuration changes on the domain controllers. 7. Rerun Dcdiag /test:CheckSecurityError /ReplSource:SourceDomainControllerName to validate configuration changes.

Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)
Domain controllers running Windows 2000 Server or Windows Server 2003 cannot replicate Active Directory updates if Domain Name System (DNS) lookup failures prevent a destination domain controller from contacting its source replication partner to request changes. Lookup failures occur when a destination domain controller cannot resolve its source replication partner's globally unique identifier (GUID)-based canonical name (CNAME) resource record to an Internet Protocol (IP) address by using DNS. GUID-based CNAME resource records are always registered in the DNS zone _msdcs.ForestRootDomain. The most common DNS failures occur when DNS client settings are misconfigured on the destination or source domain controller, or the direct and intermediate DNS servers that are used to resolve the query are misconfigured. Network problems or domain controller disconnection problems might also be present. If the problem is due to DNS configuration errors or replication latency, the effect on Active Directory replication is minimized by new improvements to domain controller name resolution in Windows Server 2003 Service Pack 1 (SP1).

Improvements to Domain Controller Name Resolution in SP1


Domain controllers running Windows Server 2003 with SP1 have a more robust response to DNS name resolution failures. Rather than failing on the first attempt to resolve the IP address of a source domain controller by using its CNAME resource record, destination domain controllers running Windows Server 2003 with SP1 use alternate names to attempt resolution and also log events that report problems and prescribe solutions.

DNS Failure Scenarios


All domain controllers register multiple service location (SRV) resource records in DNS as well as a host address (A) resource record for each IP address of the domain controller, plus an additional host resource record for each IP address if the domain controller is a global catalog server. In addition, each domain controller registers a single CNAME resource record. The following table shows the DNS resource records that are required for proper Active Directory functionality. Mnemonic pdc gc GcIpAddress DsaCname kdc dc None Type SRV SRV A CNAME SRV SRV A DNS resource record _ldap._tcp.pdc._msdcs.DnsDomainName _ldap_tcp.gc._msdcs.DnsForestRootDomainName _gc._msdcs.DnsForestRootDomainName DsaGuid._msdcs.DnsForestRootDomainName _kerberos._tcp.dc._msdcs.DnsDomainName _ldap._tcp.dc._msdcs.DnsDomainName DomainControllerFQDN

In the CNAME resource record (DSA_GUID._msdcs.ForestRootDNSDomainName), DSA_GUID is the GUID of the NTDS Settings object (also called the Directory System Agent (DSA) object) for the domain controller. ForestRootDNSDomainName is the DNS name of the forest where the domain controller is located. Destination domain controllers use the CNAME resource record to identify and locate their replication partners.

The Net Logon service on the domain controller registers all SRV resource records when the operating system starts up and at regular intervals thereafter. The DNS client service on the domain controller registers the DNS host A resource record. A domain controller uses the following steps to locate its replication partner: 1. The destination domain controller queries its DNS server to look for the CNAME resource record of its replication partner. On domain controllers running Windows 2000 Server or Windows Server 2003 with no service pack applied, if this lookup fails to resolve the CNAME resource record to an IP address, DNS lookup (and replication) fails. 2. On domain controllers running Windows Server 2003 with SP1, if the CNAME lookup is unsuccessful, the domain controller looks for the DNS A resource record of its replication partner. For example, the domain controller looks for DC03.corp.contoso.com. 3. If the DNS A resource record lookup is unsuccessful, the domain controller performs a network basic input/output system (NetBIOS) broadcast by using the host name of its replication partner. For example, the domain controller uses DC03. When lookups fail, events that describe the condition are logged in the Directory Service event log.

DNS Events for Lookup Failure


Two new events, event ID 2087 and event ID 2088, are logged on destination domain controllers running Windows Server 2003 with SP1: If all lookups fail, event ID 2087 is logged.

If lookup succeeds but either the first or second attempt fails, event ID 2088 is logged. On domain controllers running Windows 2000 Server or Windows Server 2003 with no service pack applied, the destination domain controller that cannot successfully locate its replication partner in DNS logs event ID 1925. Regardless of whether replication succeeds or fails, if you receive event ID 1925, event ID 2087, or event ID 2088, you should investigate and correct the cause of the failure because incorrect DNS configuration can affect other essential operations including logon authentication and access to network resources on member computers, domain controllers, and application servers. In addition, although fallback name resolution might allow replication to occur, it introduces unnecessary latency and overhead into the replication process.

DNS Requirements for CNAME Lookup Success


Although name resolution in Windows Server 2003 with SP1 is more aggressive at ensuring that replication can occur when a CNAME lookup fails, failure of this method indicates that either the DNS clients or DNS servers are not configured properly. It is important to understand the requirements for successful CNAME lookup and to ensure that DNS is functioning accordingly. Resolving the fully qualified, GUID-based, CNAME resource record of the source domain controller to the current IP address of the source domain controller requires the following DNS configurations: 1. In their respective TCP/IP client settings, the source domain controller and destination domain controller must be configured to resolve DNS names by using only valid DNS servers that directly host, forward, or delegate to the following DNS zones: a. _msdcs.ForestRootDNSDomainName, to resolve queries for computers in the forest. b. The DNS zone that corresponds to the primary DNS suffix of the respective target domain controller, to resolve queries for computers in the domain. (The source domain controller can resolve the domain name of the target domain controller, and the reverse is also true.) The primary DNS suffix is usually the same as the DNS name of the domain to which a computer is joined. You can view the primary DNS suffix in the properties of My Computer. If the DNS servers that the source domain controller is configured to use for name resolution do not host these zones directly, the DNS servers that are used must forward or delegate to DNS servers that do host these zones. 2. The source domain controller must have successfully registered the following resource records: GUID-based CNAME resource record in the DNS zone _msdcs.ForestRootDNSDomainName Host A resource record in the DNS zone that corresponds to its primary DNS suffix

Potential Preliminary Failures Due to Replication Latency


At the time that the destination domain controller queries its DNS servers for the location of its source replication partner, DNS configurations might be correct on both the source and destination domain controllers, but DNS resource record registrations might be in flux as a

result of configuration changes on the source domain controller. In this case, DNS lookup can fail as a result of replication latency, as follows: If the source domain controller changes the DNS server on which it registers its CNAME and host A resource records, it is possible that the initial DNS server that the destination domain controller queries to resolve the name of the source domain controller is different than any of the DNS servers on which the CNAME and host A resource records for the source domain controller are currently registered. In this case, DNS replication latency or failures might prevent DNS records that are successfully registered on the DNS servers that the source controller uses from being located by the DNS server that is queried by the destination domain controller. If the Active Directory domain of the DNS server that the destination domain controller uses initially has a parent-child relationship with the Active Directory domain of the servers on which the source domain controller registers its resource records, the forwarder and delegation configuration on both the DNS servers that the source domain controller uses and the DNS servers that the destination domain controller uses, as well as any intermediate DNS servers that are used to resolve the DNS query, must be valid. Any required records on those DNS servers might be subject to replication latency and failure. Understanding these basic requirements for name resolution that locates the source replication partner provides a more meaningful context for working through solutions when you have replication DNS lookup problems. Choose a problem from the following list that best describes your situation, and then step through the suggested fix: Event ID 1925: Attempt to establish a replication link failed due to DNS lookup problem Event ID 2087: DNS lookup failure caused replication to fail Event ID 2088: DNS lookup failure occurred with replication success

Event ID 1925: Attempt to establish a replication link failed due to DNS lookup problem
If you receive event ID 1925 with the error message that Domain Name System (DNS) lookup failed, inbound replication of a directory partition has failed on the destination domain controller, and you must fix the DNS problem. An example of the event text is as follows:

Event Type:Warning Event Source:NTDS KCC Event Category:Knowledge Consistency Checker Event ID:1925 Date:3/24/2005 Time:9:15:46 AM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: The attempt to establish a replication link for the following writable directory partition failed. Directory partition: CN=Configuration,DC=contoso,DC=com Source domain controller: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=contoso,DC=com Source domain controller address: f8786828-ecf5-4b7d-ad12-8ab60178f7cd._msdcs.contoso.com Intersite transport (if any): This domain controller will be unable to replicate with the source domain controller until this problem is corrected. User Action Verify if the source domain controller is accessible or network connectivity is available. Additional Data Error value: 8524 The DSA operation is unable to proceed because of a DNS lookup failure.

Solution
Proceed with DNS testing as described in "Event ID 2087: DNS lookup failure caused replication to fail."

Event ID 2087: DNS lookup failure caused replication to fail


When a destination domain controller running Windows Server 2003 with Service Pack 1 (SP1) receives event ID 2087 in the Directory Service event log, attempts to resolve the

globally unique identifier (GUID) in the canonical name (CNAME) resource record, the fully qualified domain name (FQDN), and the network basic input/output system (NetBIOS) name to the Internet Protocol (IP) address of the source domain controller have all failed. Failure to locate the source replication partner prevents replication with that source until the problem is fixed. An example of the event text is as follows:
Event Type:Error Event Source:NTDS Replication Event Category:DS RPC Client Event ID:2087 Date:3/9/2005 Time:11:00:21 AM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: Active Directory could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources. Source domain controller: dc2 Failing DNS host name: b0069e56-b19c-438a-8a1f-64866374dd6e._msdcs.contoso.com NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur. To log all individual failure events, set the following diagnostics registry value to 1: Registry Path: HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client User Action: 1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498. 2) Confirm that the source domain controller is running Active Directory and is accessible on the network by typing "net view \\<source DC name>" or "ping <source DC name>".

3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on http://www.microsoft.com/dns dcdiag /test:dns 4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows: dcdiag /test:dns 5) For further analysis of DNS error failures see KB 824449: http://support.microsoft.com/?kbid=824449 Additional Data Error value: 11004 The requested name is valid, but no data of the requested type was found.

Cause
Failure to resolve the current CNAME resource record of the source domain controller to an IP address can have the following causes: The source domain controller is powered off, is offline, or resides on an isolated network, and Active Directory and Domain Name System (DNS) data for the offline domain controller has not been deleted to indicate that the domain controller is inaccessible. One of the following conditions exists: The source domain controller has not registered its resource records in DNS. The destination domain controller is configured to use an invalid DNS server. The source domain controller is configured to use an invalid DNS server.

The DNS server that is used by the source domain controller does not host the correct zones or the zones are not configured to accept dynamic updates. The direct DNS servers that are queried by the destination domain controller cannot resolve the IP address of the source domain controller as a result of nonexistent or invalid forwarders or delegations.

Active Directory has been removed on the source domain controller and then reinstalled with the same IP address, but knowledge of the new NTDS Settings GUID has not reached the destination domain controller. Active Directory has been removed on the source domain controller and then reinstalled with a different IP address, but the current host address (A) resource record for the IP address of the source domain controller is either not registered or does not exist on the DNS servers that are queried by the destination domain controller as a result of replication latency or replication error. The operating system of the source domain controller has been reinstalled with a different computer name, but its metadata either has not been removed or has been removed and not yet inbound-replicated by the destination domain controller.

Solution
First, determine whether the source domain controller is functioning. If the source domain controller is not functioning, remove its remaining metadata from Active Directory. If the source domain controller is functioning, continue with procedures to diagnose and solve the DNS problem, as needed: Use Dcdiag to diagnose DNS problems. Register DNS SRV resource records plus host records. Synchronize replication between the source and destination domain controllers. Verify consistency of the NTDS Settings GUID.

Determine Whether a Domain Controller Is Functioning


To determine whether the source domain controller is functioning, use the following test. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Users group in the domain of the domain controller. Tools: Net view

To determine whether a domain controller is functioning To confirm that the domain controller is running Active Directory and is accessible on the network, at a command prompt type the following command, and then press ENTER:

net view \\SourceDomainControllerName where SourceDomainControllerName is the NetBIOS name of the domain controller. This command displays the Netlogon and SYSVOL shares, indicating that the server is functioning as a domain controller. If this test shows that the domain controller is not functioning on the network, determine the nature of the disconnection and whether the domain controller can be recovered or whether its metadata must be removed from Active Directory manually. If the domain controller is not functioning and cannot be restored, use the procedure in the following section, "Clean Up Domain Controller Metadata," to delete the data from Active Directory that is associated with that server.

Clean Up Domain Controller Metadata


If tests show that the domain controller is no longer functioning but you still see objects representing the domain controller in Active Directory Sites and Services, replication will continue to be attempted, and you must remove these objects from Active Directory manually. You must use Ntdsutil to clean up (delete) the metadata for the defunct domain controller. If the defunct domain controller is the last domain controller in the domain, you should also remove the metadata for the domain. Allow sufficient time for all global catalog servers in the forest to inbound-replicate the domain deletion before promoting a new domain with the same name. The process for cleaning up metadata is improved in the version of Ntdsutil that is included with Windows Server 2003 SP1. Instructions for cleaning up metadata with the Windows Server 2003 version of Ntdsutil and the Windows Server 2003 SP1 version of Ntdsutil are provided in the following procedure. Requirements Administrative credentials: To complete this procedure, you must be a member of the Enterprise Admins group. Tools: Ntdsutil (System32 command-line tool)

To clean up server metadata 1. Open a Command Prompt. 2. Type the following command, and then press ENTER: ntdsutil

3. At the ntdsutil: command prompt, type the following command, and then press ENTER: metadata cleanup 4. Perform metadata cleanup as follows: Note If you are removing domain metadata as well as server metadata, skip the following procedure and use the procedure that begins at step a. If you are performing server metadata cleanup only and you are using the version of Ntdsutil.exe that is included with Windows Server 2003 SP1, at the metadata cleanup: command prompt, type the following, and then press ENTER: remove selected server ServerName Or remove selected server ServerName1onServerName2 Value ServerName, ServerName1 Description The distinguished name of the domain controller whose metadata you want to remove, in the form cn=ServerName,cn=Servers,cn=SiteName, cn=Sites,cn=Configuration,dc=ForestRootDomain The DNS name of the domain controller to which you want to connect and from which you want to remove server metadata

ServerName2

If you are performing metadata cleanup by using the version of Ntdsutil.exe that is included with Windows Server 2003 with no service pack, or if you are performing both domain metadata cleanup and server metadata cleanup, perform metadata cleanup as follows: a. At the metadata cleanup: command prompt, type the following command, and then press ENTER: connection b. At the server connections: command prompt, type the following command, and then press ENTER:

connect to server Server c. At the connection: command prompt, type the following command, and then press ENTER: quit d. At the metadata cleanup: command prompt, type the following command, and then press ENTER: select operation target e. At the select operation target: command prompt, type the following command, and then press ENTER: list sites f. A numbered list of sites appears. Type the following command, and then press ENTER: select site SiteNumber g. At the select operation target: command prompt, type the following command, and then press ENTER: list domains in site h. A numbered list of domains in the selected site appears. Type the following command, and then press ENTER: select domain DomainNumber i. At the select operation target: command prompt, type the following command, and then press ENTER: list servers in site j. A numbered list of servers in a domain and site is displayed. Type the following command, and then press ENTER: select server ServerNumber k. At the select operation target: command, type the following command, and then press ENTER: quit l. At the metadata cleanup: command, type the following command, and then press ENTER: remove selected server

m. If the server whose metadata you have removed is the last domain controller in the domain and you want to remove the domain metadata, at the metadata cleanup: command prompt, type the following command, and then press ENTER: remove selected domain Metadata for the domain that you selected in step h is removed. n. At the metadata cleanup: and ntdsutil: command prompts, type quit, and then press ENTER. Value Server Description The DNS name of a domain controller that you want to connect to The number that is associated with the site of the server that you want to clean up, which appears in the list The number that is associated with the domain of the server that you want to clean up, which appears in the list The number that is associated with the server that you want to clean up, which appears in the list

SiteNumber

DomainNumber

ServerNumber

Use Dcdiag to Diagnose DNS Problems


If the domain controller is functioning online, continue by using Dcdiag to diagnose and fix DNS problems that might be interfering with Active Directory replication. Use the following procedures to complete this process: Verify connectivity and basic DNS functionality. Verify registration of the CNAME resource record in DNS. Verify and enable secure dynamic updates.

Before you begin these procedures, gather the following information, which is contained in the event ID 2087 message text: The FQDN of the source domain controller and destination domain controller The IP address of the source domain controller

The updated version of Dcdiag that is included in Windows Support Tools in Windows Server 2003 SP1 contains tests that provide consolidated and improved testing of basic and advanced DNS features. You can use this tool to diagnose basic DNS functionality and dynamic updates. When you use the enhanced SP1 version of Dcdiag for DNS testing, there are specific requirements that do not apply to all Dcdiag tests. Requirements Administrative credentials: To complete the new DNS tests that are available in the SP1 version of Dcdiag, you must be a member of the Enterprise Admins group. Tools: Dcdiag.exe Operating system: You can run the enhanced version of Dcdiag on computers running the following operating systems: Windows XP Professional Windows Server 2003 Windows Server 2003 with SP1 You can run the new Dcdiag DNS tests against Microsoft DNS servers that are installed on domain controllers running the following operating systems: Windows 2000 Server with Service Pack 3 (SP3) Windows 2000 Server with Service Pack 4 (SP4) Windows Server 2003 Windows Server 2003 with SP1 Note You can use the /f: switch in Dcdiag commands to save the output to a text file. Use /f:FileName to generate the file in the location that is indicated in FileName, for example, /f:c:\Test\DnsTest.txt.

Verify Basic DNS Functionality


To verify the settings that might interfere with Active Directory replication, you can begin by running the basic DNS test that ensures that DNS is operating properly on the domain controller. The basic DNS test checks the following: Connectivity: The test determines whether domain controllers are registered in DNS, can be contacted by PING, and have Lightweight Directory Access Protocol / remote procedure call (LDAP/RPC) connectivity. If the connectivity test fails on a domain controller, no other tests are run against that domain controller. The connectivity test is performed automatically before any other DNS test is run. Essential services: The test confirms that the following services are running and available on the tested domain controller: DNS Client service Net Logon service Key Distribution Center (KDC) service DNS Server service (if DNS is installed on the domain controller)

DNS client configuration: The test confirms that DNS servers on all adapters are reachable. Resource record registrations: The test confirms that the address (A) resource record of each domain controller is registered on at least one of the DNS servers that is configured on the client. Zone and server of authority (SOA): If the domain controller is running the DNS Server service, the test confirms that the Active Directory domain zone and SOA record for the Active Directory domain zone are present. Root zone: Checks if the root (.) zone is present.

To verify basic DNS functionality 1. At a command prompt, type the following command, and then press ENTER: dcdiag /test:dns /s:SourceDomainControllerName /DnsBasic where SourceDomainControllerName is the distinguished name, NetBIOS name, or DNS name of the domain controller. As an alternative, you can test all domain controllers in the forest by typing /e: instead of /s:.

2. Copy the report into Notepad or an equivalent text editor. 3. Scroll to the Summary table near the bottom of the Dcdiag log file. 4. Note the names of all domain controllers that report Warn or Fail status in the Summary table. 5. Find the detailed breakout section for the problem domain controller by searching on the string DC: DomainControllerName. 6. Make the required configuration changes on DNS clients and DNS servers. 7. To validate the configuration changes, rerun Dcdiag /test:DNS with the /e: or /s: switch. If the basic DNS test shows no errors, continue by verifying that resource records that are used to locate domain controllers are registered in DNS.

Verify Resource Record Registration


The destination domain controller uses the DNS CNAME resource record to locate its source domain controller replication partner. Although domain controllers running Windows Server 2003 with SP1 can locate source replication partners by using FQDNs or, if that fails, NetBIOS names, the presence of the CNAME record is expected and should be verified for proper DNS functioning. You can use Dcdiag to verify registration of all resource records that are essential for domain controller location by using the dcdiag /test:dns /DnsRecordRegistration test. This test verifies registration of the following resource records in DNS: CNAME (the GUID-based resource record that locates a replication partner) A (the host resource record that contains the IP address of the domain controller) LDAP SRV (the service resource records that locate LDAP servers) GC SRV (the service resource records that locate global catalog servers)

PDC SRV (the service resource records that locate primary domain controller (PDC) operations masters) As an alternative, you can use the following procedure to check for only the CNAME resource record. To verify CNAME resource record registration 1. In the DNS console, locate any domain controller that is running the DNS Server service, where the server hosts the DNS zone with the same name as the

Active Directory domain of the domain controller. 2. In the console tree, click the zone that is named _msdcs.Dns_Domain_Name. Note In Windows 2000 Server DNS, _msdcs.Dns_Domain_Name is a subdomain of the DNS zone for the Active Directory domain name. In Windows Server 2003 DNS, _msdcs.Dns_Domain_Name is a separate zone. 3. In the details pane, verify that the following resource records are present: A CNAME resource record that is named Dsa_Guid._msdcs.Dns_Domain_Name A corresponding A resource record for the name of the DNS server

If the CNAME resource record is not registered, verify that dynamic updates are functioning properly. Use the test in the following section.

Verify Dynamic Updates


If the basic DNS test shows that resource records do not exist in DNS, use the dynamic update test to diagnose why the Net Logon service did not register the resource records automatically. To verify that the Active Directory domain zone is configured to accept secure dynamic updates and to perform registration of a test record (_dcdiag_test_record), use the following procedure. The test record is deleted automatically after the test. To verify dynamic updates At a command prompt, type the following command, and then press ENTER:

dcdiag /test:dns /s:SourceDomainControllerName /DnsDynamicUpdate where SourceDomainControllerName is the distinguished name, NetBIOS name, or DNS name of the domain controller. As an alternative, you can test all domain controllers by using the /e: switch instead of the /s: switch. If secure dynamic update is not configured, use the following procedure to configure it. To enable secure dynamic updates 1. Open the DNS console. 2. In the console tree, right-click the applicable zone, and then click Properties.

3. On the General tab, verify that the zone type is Active Directoryintegrated. 4. In Dynamic Updates, click Secure only.

Register DNS Resource Records


If DNS resource records do not appear in DNS for the source domain controller, you have verified dynamic updates, and you want to register DNS resource records immediately, you can force the registration manually by using the following procedure. The Net Logon service on a domain controller registers the DNS resource records that are required for the domain controller to be located on the network. The DNS Client service registers the host A resource record that the CNAME record points to. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or a member of the Enterprise Admins group. Tools: net stop/start, ipconfig

To register DNS resource records manually 1. To initiate registration of domain controller Locator resource records manually on the source domain controller, at a command prompt type the following commands, and then press ENTER after each command: net stop net logon & net start net logon 2. To initiate registration of the host A resource record manually, at a command prompt type the following command, and then press ENTER: ipconfig /flushdns & ipconfig /registerdns 3. Wait 15 minutes, and then review events in Event Viewer to ensure proper registration of the resource records. Repeat the procedure in the "Verify Resource Record Registration" section earlier in this guide to verify that the resource records appear in DNS.

Synchronize Replication Between the Source and Destination Domain Controllers


After you complete DNS testing, use the following procedure to synchronize replication on the inbound connection from the source domain controller to the destination domain controller.

Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the domain of the destination domain controller. Tool: Active Directory Sites and Services

To synchronize replication from a source domain controller 1. Open Active Directory Sites and Services. 2. In the console tree, double-click the Sites container, double-click the site of the domain controller to which you want to synchronize replication, double-click the Servers container, double-click the server object of the domain controller, and then click NTDS Settings. 3. In the details pane, in the From Server column, locate the connection object that shows the name of the source domain controller. 4. Right-click the appropriate connection object, and then click Replicate Now. 5. Click OK. If replication does not succeed, use the procedure in the following section to verify consistency of the NTDS Settings GUID.

Verify Consistency of the NTDS Settings GUID


If you have performed all DNS tests and other tests and replication does not succeed, use the following procedure to verify that the GUID of the NTDS Settings object that the destination domain controller is using to locate its replication partner matches the GUID that is currently in effect on the source domain controller itself. To perform this test, you view the object GUID as it appears in the local directories of each domain controller. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the domain of the destination domain controller. Tool: Ldp (Windows Support Tools)

To verify consistency of the NTDS Settings GUID 1. Click Start, click Run, type Ldp, and then click OK. 2. On the Connection menu, click Connect. 3. In the Connect dialog box, leave the Server box empty.

4. In Port, type 389, and then click OK. 5. On the Connection menu, click Bind. 6. In the Bind dialog box, provide Enterprise Admins credentials. If it is not already selected, click Domain. 7. In Domain, type the name of the forest root domain, and then click OK. 8. On the View menu, click Tree. 9. In the Tree View dialog box, type: CN=Configuration,DC=Forest_Root_Domain and then click OK. 10. Navigate to the object CN=NTDS Settings,CN=SourceServerName,CN=Servers,CN=SiteName, CN=Sites,CN=configuration,DC=ForestRootDomain. 11. Double-click the NTDS Settings object and, in the details pane, view the value for the attribute objectGUID. Right-click that value, and then copy it to Notepad. 12. On the Connection menu, click Disconnect. 13. Repeat steps 2 through 11, but in step 3, type the name of the source domain controller, for example, DC03. 14. In Notepad, compare the values of the two GUIDs. 15. If the values do not match, the destination domain controller must receive replication of the valid GUID. Check the GUID value on other domain controllers and attempt replication on the destination domain controller with a different domain controller that has the correct GUID. 16. If the values match, verify that the GUID matches the GUID in the Dsa_Guid._msdcs.Dns_Domain_Name resource record for the source domain controller, as follows: a. Note the primary DNS servers that each domain controller identifies in the TCP/IP properties in their Network Settings. All the DNS servers that are listed in the respective TCP/IP properties should be able to indirectly or directly resolve this CNAME resource record. b. From the servers that are listed, identify the authoritative name server or servers for this domain zone by looking at the server names that are listed for the name server (NS) resource records at the root of the zone. (In the DNS console, select the forward lookup zone for the root domain, and view the NS

records in the details pane). c. On the name server or servers obtained in step b, open the DNS console, and double-click the forward lookup zone for the forest root domain name. Double-click the _msdcs folder, and note the CNAME resource records that exist for your server name. d. If there are no records present or the records are incorrect, see article 241505, SRV Records Missing After Implementing Active Directory and Domain Name System, on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=69994).

Event ID 2088: DNS lookup failure occurred with replication success


When a destination domain controller running Windows Server 2003 with Service Pack 1 (SP1) receives event ID 2088 in the Directory Service event log, attempts to resolve the globally unique identifier (GUID) in the canonical name (CNAME) resource record to an Internet Protocol (IP) address for the source domain controller failed. However, the destination domain controller tried other means to resolve the name and succeeded by using either the fully qualified domain name (FQDN) or the network basic input/output system (NetBIOS) name of the source domain controller. Although replication was successful, the DNS problem should be diagnosed and resolved. An example of the event text is as follows:
Event Type:Warning Event Source:NTDS Replication Event Category:DS RPC Client Event ID:2088 Date:3/21/2005 Time:2:29:34 PM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: Active Directory could not use DNS to resolve the IP address of the source domain controller listed below. To maintain the consistency of Security groups, group policy, users and computers and their passwords, Active Directory successfully replicated using the NetBIOS or fully qualified computer name of the source domain controller. Invalid DNS configuration may be affecting other essential operations on member computers, domain controllers or application servers in this

Active Directory forest, including logon authentication or access to network resources. You should immediately resolve this DNS configuration error so that this domain controller can resolve the IP address of the source domain controller using DNS. Alternate server name: dc1 Failing DNS host name: 4a8717eb-8e58-456c-995a-c92e4add7e8e._msdcs.contoso.com NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur. To log all individual failure events, set the following diagnostics registry value to 1: Registry Path: HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client User Action: 1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498. 2) Confirm that the source domain controller is running Active Directory and is accessible on the network by typing "net view \\<source DC name>" or "ping <source DC name>". 3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on http://www.microsoft.com/dns dcdiag /test:dns 4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows: dcdiag /test:dns 5) For further analysis of DNS error failures see KB 824449: http://support.microsoft.com/?kbid=824449 Additional Data Error value: 11004 The requested name is valid, but no data of the requested type was found

Cause
Failure to resolve the source domain controller name by using the CNAME resource record in DNS can be due to DNS misconfigurations or delays in DNS data propagation.

Solution
Proceed with DNS testing as described in "Event ID 2087: DNS lookup failure caused replication to fail."

Fixing Replication Connectivity Problems (Event ID 1925)


Network connectivity problems can make it impossible for domain controllers to form replication partnerships. Various events and errors can indicate a problem with network connectivity that is preventing replication from occurring. Use the procedures in Event ID 1925: Attempt to establish a replication link failed due to connectivity problem to diagnose and fix replication connectivity problems.

Event ID 1925: Attempt to establish a replication link failed due to connectivity problem
The description text in event ID 1925 reports that the attempt to establish a replication link for the following writable directory partition failed, and the description text provides the distinguished name of the directory partition that the destination is attempting to replicate from the source. The error code in the event gives more specific information about the cause of the problem. An example of the event text is as follows:
Event Event Event Event Type:Warning Source:NTDS KCC Category:Knowledge Consistency Checker ID:1925

Date:3/24/2005 Time:9:15:46 AM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: The attempt to establish a replication link for the following writable directory partition failed. Directory partition: CN=Configuration,DC=contoso,DC=com Source domain controller: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=contoso,DC=com Source domain controller address: f8786828-ecf5-4b7d-ad12-8ab60178f7cd._msdcs.contoso.com Intersite transport (if any): CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=contoso,DC=com This domain controller will be unable to replicate with the source domain controller until this problem is corrected. User Action Verify if the source domain controller is accessible or network connectivity is available. Additional Data Error value: 1908 Could not find the domain controller for this domain.

Cause
When event ID 1925 contains error 1908, "Could not find the domain controller for this domain," Active Directory replication has failed as a result of a connectivity problem between the domain controller that reported the error and the source domain controller that is named in the event text.

Solution
Use the following tests to solve this problem: Verify wide area network (WAN) connectivity. Determine the maximum packet size, and change it if necessary. Force replication, and capture replication traffic in Network Monitor.

Analyze network traces to see if any traffic is not reaching the source domain controller.

Verify WAN Connectivity


Verify that there are no basic connectivity problems with the underlying network between the domain controllers, especially if they are separated by a WAN link or firewalls. For information about testing this type of problem, see article 310099, Description of the Portquery.exe command-line utility, on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=69995), and see article 159211, Diagnoses and treatment of black hole routers, on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=69996).

Determine Maximum Packet Size


By default, the Kerberos authentication protocol in Windows 2000, Windows XP, and Windows Server 2003 uses the User Datagram Protocol (UDP) when the data can be fit in packets of less than 2,000 bytes. Any data above this value uses TCP to carry the packets. Packets of more than 1,500 bytes are often dropped by a device such as a firewall on the network. To avoid this problem, you can determine the size of packet that your network can accommodate. Then, you can edit the registry so that the maximum number of bytes for using UDP is set to the lowest value that you receive, less 8 bytes to account for header size. Use the ping command to test the size of packets that the network can accommodate. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Users group and have the Log on locally right on the domain controller. Tool: PING

To determine the lowest common packet size 1. From the destination domain controller, ping the source domain controller by its Internet Protocol (IP) address. At a command prompt, type the following command, and then press ENTER: ping IP_address -f -l 1472 2. From the source domain controller, use the command in step 1 to ping the destination domain controller by its IP address. 3. If the ping command completes in both directions, no additional modification is required.

4. If the ping command fails in either direction, monotonically lower the number that you use in the -l parameter until you find the lowest common packet size that works between the source and destination domain controllers. Note The version of Dcdiag that is included with Windows Server 2003 SP1 Support Tools provides the following method to perform this test: dcdiag /test:CheckSecurityError /s:SourceDomainControllerName You can edit the registry to set the maximum size of packets to the value that you determined by the PING method, less 8 bytes to account for header size. As an alternative, you can edit the registry so that the maximum number of bytes for using UDP is always exceeded and Kerberos always uses TCP. You can change the default value of 2,000 bytes by modifying the registry entry MaxPacketSize in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ Kerberos\Parameters. Use the following procedure to change this registry setting. Caution It is recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use extreme caution. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the domain of the domain controller. Tool: Regedit.exe change the maximum packet size

To change the maximum packet size 1. Click Start, click Run, type regedit, and then click OK. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ Kerberos\Parameters. 3. Edit or, if it does not exist in the details pane, create the entry MaxPacketSize as follows:

To edit the entry if it exists in the details pane:

Right-click MaxPacketSize; click Modify; and then, in the Value data box, type 1 to force Kerberos to use TCP, or type the value that you established to lower the value to the appropriate maximum size. To create the entry if it does not exist in the details pane:

Right-click Parameters, click New DWORD Value, type the name MaxPacketSize, and then go to step 3a to edit the entry. 4. Click OK. 5. You must restart the domain controller for this change to take effect. For information about importing an Administrative Template into Group Policy so that this value can be set for all the Windows 2000based, Windows Server 2003-based, or Windows XP-based computers in the enterprise, see article 244474, "How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000," on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=69997).

Capture Network Traces During Replication


Use Network Monitor to capture simultaneous traces on both source and destination domain controllers while attempting to replicate (all traffic to and from each domain controller; plus, set the capture buffer to a sufficiently large value). You must select the addresses of the domain controllers from the address database and add them to the capture filter. Start the capture, and then start replication between the two domain controllers. Look for Kerberos fragmentation, out-of-order packets, latency, or network traffic that originates on one side of the connection and does not arrive at the other side. For information about installing Network Monitor, see Network Monitor on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=42987).

Create an Address Database


To use address pairs in a capture filter, you must first build an address database. After the database is created, you can use the addresses that are listed in the database to specify address pairs in a capture filter. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or the Enterprise Admins group. Tool: Network Monitor

To create an address database 1. Open Network Monitor. 2. If you are prompted, select the local network from which you want to capture data by default. 3. On the Capture menu, click Start. 4. On the Capture menu, click Stop and View. 5. On the Display menu, click Find All Names. 6. In the Find All Names dialog box, click OK. All addresses are added to the address database. 7. On the Window menu, click the local connection. You can use the names in the addresses database to specify address pairs in the capture filter.

Capture Network Frames


To capture frames that are sent from a specific computer on your network to your computer or that are sent from your computer to a specific computer on your network, specify one or more address pairs in a capture filter. You can monitor up to four address pairs simultaneously. An address pair consists of: The addresses of the two computers between which you want to monitor traffic. Arrows that specify the traffic direction that you want to monitor.

The INCLUDE or EXCLUDE keywords, which indicate how Network Monitor should respond to a frame that meets a filter's specifications. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or the Enterprise Admins Group in the forest. Tool: Network Monitor

To capture network frames 1. Open Network Monitor. 2. If you are prompted, select the local network from which you want to capture

data by default. 3. On the Capture menu, click Buffer Settings. 4. In the Capture Buffer Settings dialog box, set the buffer and frame size as appropriate, and then click OK. 5. On the Capture menu, click Filter. 6. In the Capture Filter dialog box, double-click Address Pairs. 7. In the Address Expressions dialog box, select an address in Station 1 and an address in Station 2 for the computers whose traffic you want to capture. 8. In the Direction box, select one of the symbols: <--> to monitor the traffic that passes in either direction between the addresses that you have selected. --> or <-- to monitor only the traffic that passes in one direction between the computers.. 9. Click OK twice. 10. On the Capture menu, click Start.

Force Replication
When you have Network Monitor started to capture traffic between the two domain controllers, use the following procedure to force synchronization between the computers so that you can capture the replication traffic in Network Monitor. Requirements Credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or the Enterprise Admins group in the forest. Tools: Active Directory Sites and Services (Administrative Tools)

To synchronize replication from a source domain controller 1. Open Active Directory Sites and Services. 2. Double-click the Sites container, double-click the site of the domain controller to which you want to synchronize replication, double-click the Servers container, double-click the server object of the domain controller, and then click NTDS Settings. 3. In the From Server column in the details pane, locate the connection object

that shows the name of the source domain controller. 4. Right-click the appropriate connection object, and then click Replicate Now. 5. Click OK. Analyze the traces from both domain controllers to see if there is any traffic that is not getting to the other domain controller. For information about using Network Monitor, see Network Monitor overview on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=41936).

Fixing Replication Topology Problems (Event ID 1311)


The Knowledge Consistency Checker (KCC) constructs and maintains the Active Directory replication topology automatically. Every 15 minutes, the KCC examines the sum of all directory partition replicas that reside on domain controllers in the forest, as well as administrator-defined settings for connections, sites, and site links. Although generation of the replication topology occurs automatically, administrative configuration errors can result in an Active Directory replication topology that is inconsistent with the physical connections that are available. In Active Directory it is possible to create objects for which there is no physical network support. For example, Active Directory Sites and Services allows you to create a site object and assign subnet addresses that do not exist. The KCC will attempt to use these objects to create connections between domain controllers, but replication cannot occur because the network does not exist to support the replication topology as it is configured. Event ID 1311 is logged in the Directory Service event log when the replication configuration information in Active Directory does not accurately reflect the physical topology of the network. Use the procedures in Event ID 1311: Replication configuration does not reflect the physical network to identify and fix topology problems.

Event ID 1311: Replication configuration does not reflect the physical network
Event ID 1311 is logged in the Directory Service log when configuration errors or unavailable domain controllers prevent replication of a directory partition between domain controllers in different sites.

An example of the event text is as follows:


Event Type:Error Event Source:NTDS KCC Event Category:Knowledge Consistency Checker Event ID:1311 Date:3/9/2005 Time:6:39:58 PM User:NT AUTHORITY\ANONYMOUS LOGON Computer:DC3 Description: The Knowledge Consistency Checker (KCC) has detected problems with the following directory partition. Directory partition: CN=Configuration,DC=contoso,DC=com There is insufficient site connectivity information in Active Directory Sites and Services for the KCC to create a spanning tree replication topology. Or, one or more domain controllers with this directory partition are unable to replicate the directory partition information. This is probably due to inaccessible domain controllers. User Action Use Active Directory Sites and Services to perform one of the following actions: - Publish sufficient site connectivity information so that the KCC can determine a route by which this directory partition can reach this site. This is the preferred option. - Add a Connection object to a domain controller that contains the directory partition in this site from a domain controller that contains the same directory partition in another site. If neither of the Active Directory Sites and Services tasks correct this condition, see previous events logged by the KCC that identify the inaccessible domain controllers.

Cause
This problem can have the following causes: 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 site link. Bridge all site links is enabled in Active Directory Sites and Services, but the network does not allow network connectivity between any two domain controllers in the forest.

One or more sites are not contained in a site link.

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 directory partition between Active Directory sites. Administrator-defined preferred bridgehead servers are online, but they do not host the required directory partition. The most common misconfiguration is to define non global catalog servers as bridgehead servers. Preferred bridgeheads are defined correctly by the administrator, but they are currently offline. The bridgehead server is overloaded because the server is undersized, too many branch sites are trying to replicate changes from the same hub domain controller, or the replication schedules on site links or connection objects are too frequent. The Knowledge Consistency Checker (KCC) has built an alternate path around an intersite connection failure, but it continues to retry the failing connection every 15 minutes.

Solution
Use the following procedures for troubleshooting event ID 1311: Identify the scope of the problem. Check site link bridging. Determine whether the network is fully routed. Verify that all sites are connected. Check preferred bridgehead servers.

Identify the Scope of the Problem


Identify the scope of the problem by determining whether 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. First, use the following procedure to locate the ISTG role holders for all sites. Requirements

Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in a domain in the forest. Tool: Ldp (Windows Support Tools)

To locate the ISTG role holders for all sites 1. Click Start, click Run, type Ldp, and then click OK. 2. On the Connection menu, click Connect. 3. In the Connect dialog box, leave the Server box empty. 4. In Port, type 389, and then click OK. 5. On the Connection menu, click Bind. 6. In the Bind dialog box, provide Enterprise Admins credentials. Click Domain if it is not already selected. 7. In Domain, type the name of the forest root domain, and then click OK. 8. On the Browse menu, click Search. 9. In Base dn, type: CN=Sites,CN=Configuration,DC=Forest_Root_Domain 10. In Filter, type: (CN=NTDS Site Settings) 11. For Scope, click Subtree. 12. Click Options, and in the Attributes box, scroll to the end of the list, type: ;interSiteTopologyGenerator and then click OK. 13. In the Search dialog box, click Run. 14. Review the interSiteTopologyGenerator entries in the output, and make a note of the domain controller names. 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.

Check Site Link Bridging


Use the following procedure to determine if site link bridging is enabled. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in a domain in the forest. Tool: Active Directory Sites and Services (Administrative Tools)

Determine if site link bridging is enabled 1. Open Active Directory Sites and Services. 2. In the console tree, double-click the Sites container, and then double-click the Inter-Site Transports container. 3. Right-click the IP container. If Bridge all site links is selected, site link bridging is enabled. The Bridge all site links setting requires a fully routed network. If the network is not fully routed, you must create site link bridges manually.

Determine Whether the Network Is Fully Routed


Determine whether a fully routed network connection exists between two sites. If the network is fully routed, continue by verifying that the sites are connected. If the network is not fully routed and site link bridging is enabled, either make the network fully routed, or disable site link bridging and then create the necessary site links and site link bridges. For information about creating site links, see Linking Sites for Replication. Note Site link bridging is enabled by default. As a best practice, leave site link bridging enabled for fully routed networks.

Disable Site Link Bridging


If the network is not fully routed and site link bridging is enabled, use the following procedure to disable site link bridging. Requirements

Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or a member of the Enterprise Admins group. Tool: Active Directory Sites and Services (Administrative Tools)

Determine if site link bridging is enabled 1. Open Active Directory Sites and Services. 2. In the console tree, double-click the Sites container, and then double-click the Inter-Site Transports container. 3. Right-click the IP container. If Bridge all site links is selected, click it to disable it.

Create a Site Link Bridge


If the network is not fully routed, be sure that you have created site links to connect all sites. When all site links are created, use the following procedure to create a site link bridge. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or a member of the Enterprise Admins group. Tool: Active Directory Sites and Services (Administrative Tools)

To create a site link bridge 1. Open Active Directory Sites and Services. 2. In the console tree, double-click the Sites container, and then expand the Inter-Site Transports container. 3. Right-click the IP container, and then click New Site Link Bridge. 4. In Name, type a name for the site link bridge. 5. Click two or more site links to be bridged, and then click Add. 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.

Verify That All Sites Are Connected


If the network is fully routed, use the Repadmin command-line tool to view site links to ensure that intersite replication can occur between domain controllers in different sites. Requirements Administrative credentials: To complete this procedure, you must be a member of the Enterprise Admins group or the Domain Admins group in the forest root domain. Tool: Repadmin.exe (Windows Support Tools)

To view site links 1. At a command prompt, type the following command, and then press ENTER: repadmin /showism "CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=Forest_Root_Domain" where Forest_Root_Domain is the name of the forest root domain. 2. In the output, review the information for the sites that are listed. For each site, the output of the command shows 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.

Check Preferred Bridgehead Servers


If you have designated preferred bridgehead servers, the ISTG selects bridgehead servers only from that list of servers. If no servers in the list for the site can replicate a domain directory partition that has domain controllers in other sites, the ISTG selects a bridgehead server that can replicate the domain, if one is available in the site. However, if at least one server in the list can replicate a domain but the server is unavailable, the ISTG does not select an alternate bridgehead server and replication of updates to that domain does not occur in the site. In this case, you might have domain controllers that are capable of replicating the domain, but replication does not occur because preferred bridgehead servers have been selected and none is available for the domain. Check the list of preferred bridgehead servers in the site, and ensure that preferred bridgehead servers for the domain in question are available. Use the following procedure to check the list of preferred bridgehead servers. To see all servers that have been selected as preferred bridgehead servers in a forest, you can use ADSI Edit to view the bridgeheadServerListBL attribute on the IP container object. Requirements

Administrative credentials: To complete this procedure, you must be a member of the Domain Users group in a domain in the forest. Tool: Adsiedit.msc (Windows Support Tools)

To view the list of preferred bridgehead servers 1. Click Start, click Run, type adsiedit.msc, and then click OK. 2. In the console tree, double-click Configuration Container, and then doubleclick CN=Configuration,DC=ForestRootDomainName, CN=Sites, and CN=Inter-Site Transports. 3. Right-click CN=IP, and then click Properties. 4. In Attributes, double-click bridgeheadServerListBL. 5. If any preferred bridgehead servers are selected in any site in the forest, the Values box displays the distinguished name for each server object that is currently selected as a preferred bridgehead server. Verify that all domain controllers in the list are online and functioning as domain controllers. Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Users group in the domain of the domain controller. Tool: Net view

To determine whether a domain controller is functioning To confirm that a domain controller is running Active Directory and is accessible on the network, at a command prompt type the following command, and then press ENTER: net view \\DomainControllerName where DomainControllerName is the network basic input/output system (NetBIOS) name of the domain controller. This command displays the Netlogon and SYSVOL shares, indicating that the server is functioning as a domain controller. If this test shows that the domain controller is not functioning on the network, determine the nature of the disconnection and whether the domain controller can be recovered. If a domain controller that is selected as a preferred bridgehead server is not available, use the following procedure to select another preferred bridgehead server in the site that can replicate the domain.

Requirements Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the domain of the selected domain controller or a member of the Enterprise Admins group. Tool: Active Directory Sites and Services (Administrative Tools)

To designate a preferred bridgehead server 1. Open Active Directory Sites and Services. 2. In the console tree, double-click the Sites container, and then expand the Servers container. 3. Right-click the server object for the domain controller that you want to make a preferred bridgehead server, and then click Properties. 4. On the General tab, click the intersite transport or transports for which this server will be a preferred bridgehead server, and then click Add.

Additional Resources for Troubleshooting Active Directory


For specific information about troubleshooting Active Directory problems, see the following resources: Active Directory Management Pack Technical Reference for MOM 2005 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41369) For information about Active Directory known issues and best practices, see the following resources: Known Issues for Creating Domain and Forest Trusts Best Practices for Domain and Forest Trusts

For general information about how Active Directory works and how to manage and configure Active Directory, see the following resources: Administering Active Directory Operations

Active Directory Collection on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=34157)

Vous aimerez peut-être aussi