Active Directory Domain Services Operations Guide

Published on December 2016 | Categories: Documents | Downloads: 51 | Comments: 0 | Views: 480
of 554
Download PDF   Embed   Report

Comments

Content

Active Directory Domain Services Operations Guide
Microsoft Corporation Published: September 2008

Abstract
This operations guide provides administering and management information for Active Directory® Domain Services (AD DS) directory service technologies in the Windows Server® 2008 operating system.

Copyright information
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. © 2008 Microsoft Corporation. All rights reserved. Active Directory, Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents
Active Directory Domain Services Operations Guide........................................................................1 Abstract....................................................................................................................................1 Copyright information.......................................................................................................................2 Contents..........................................................................................................................................3 Active Directory Domain Services Operations Guide......................................................................24 New in This Guide.........................................................................................................................24 Administering Active Directory Domain Services............................................................................24 Introduction to Administering Active Directory Domain Services.....................................................25 When to use this guide...............................................................................................................25 How to use this guide.................................................................................................................26 Administering Domain and Forest Trusts.......................................................................................26 Introduction to Administering Domain and Forest Trusts................................................................27 Best Practices for Administering Domain and Forest Trusts...........................................................27 Managing Domain and Forest Trusts.............................................................................................28 Creating Domain and Forest Trusts...............................................................................................28 New Trust Wizard terminology....................................................................................................29 Known Issues for Creating Domain and Forest Trusts....................................................................30 Creating External Trusts................................................................................................................31 Create a One-Way, Incoming, External Trust for One Side of the Trust..........................................33 Create a One-Way, Incoming, External Trust for Both Sides of the Trust........................................34 Create a One-Way, Outgoing, External Trust for One Side of the Trust..........................................36 Create a One-Way, Outgoing, External Trust for Both Sides of the Trust........................................37 Create a Two-Way, External Trust for One Side of the Trust...........................................................39 Create a Two-Way, External Trust for Both Sides of the Trust........................................................40 Creating Shortcut Trusts................................................................................................................42 Create a One-Way, Incoming, Shortcut Trust for One Side of the Trust..........................................43

Create a One-Way, Incoming, Shortcut Trust for Both Sides of the Trust........................................44 Create a One-Way, Outgoing, Shortcut Trust for One Side of the Trust..........................................45 Create a One-Way, Outgoing, Shortcut Trust for Both Sides of the Trust........................................47 Create a Two-Way, Shortcut Trust for One Side of the Trust...........................................................48 Create a Two-Way, Shortcut Trust for Both Sides of the Trust........................................................50 Creating Forest Trusts...................................................................................................................51 Create a One-Way, Incoming, Forest Trust for One Side of the Trust.............................................52 Create a One-Way, Incoming, Forest Trust for Both Sides of the Trust...........................................54 Create a One-Way, Outgoing, Forest Trust for One Side of the Trust.............................................55 Create a One-Way, Outgoing, Forest Trust for Both Sides of the Trust...........................................57 Create a Two-Way, Forest Trust for One Side of the Trust..............................................................58 Create a Two-Way, Forest Trust for Both Sides of the Trust...........................................................60 Creating Realm Trusts...................................................................................................................62 Create a One-Way, Incoming, Realm Trust....................................................................................62 Create a One-Way, Outgoing, Realm Trust....................................................................................64 Create a Two-Way, Realm Trust.....................................................................................................65 Configuring Domain and Forest Trusts...........................................................................................66 Validating and Removing Trusts.....................................................................................................66 Validate a Trust..............................................................................................................................67 Validating a trust.........................................................................................................................67 Remove a Manually Created Trust.................................................................................................68 Removing a manually created trust............................................................................................68 Modifying Name Suffix Routing Settings........................................................................................69 Modify Routing for a Forest Name Suffix........................................................................................70 71 Modify Routing for a Subordinate Name Suffix...............................................................................71 72 Exclude Name Suffixes from Routing to a Forest...........................................................................72 72

Securing Domain and Forest Trusts...............................................................................................73 Configuring SID Filter Quarantining on External Trusts..................................................................73 Disable SID filter Quarantining.......................................................................................................75 See Also.....................................................................................................................................76 Reapply SID Filter Quarantining....................................................................................................76 Configuring Selective Authentication Settings................................................................................77 Enable Selective Authentication over an External Trust..................................................................78 Enabling selective authentication over an external trust..............................................................78 Enable Selective Authentication over a Forest Trust.......................................................................80 Enabling selective authentication over a forest trust...................................................................80 Enable Domain-Wide Authentication over an External Trust...........................................................81 Enable Forest-Wide Authentication over a Forest Trust..................................................................82 Grant the Allowed to Authenticate Permission on Computers in the Trusting Domain or Forest......83 Appendix: New Trust Wizard Pages...............................................................................................84 Direction of Trust........................................................................................................................84 Wizard option—Two-way........................................................................................................84 Wizard option—One-way: incoming........................................................................................85 Wizard option—One-way: outgoing.........................................................................................86 Sides of trust..............................................................................................................................87 Wizard option—This domain only............................................................................................87 Wizard option—Both this domain and the specified domain....................................................88 Administering the Windows Time Service......................................................................................88 Introduction to Administering the Windows Time Service................................................................88 Windows time source selection...................................................................................................88 External NTP time servers..........................................................................................................89 W32tm and net time...................................................................................................................90 Managing the Windows Time Service............................................................................................90 Configuring a Time Source for the Forest.......................................................................................91 Configure the Time Source for the Forest......................................................................................93 Change the Windows Time Service Configuration on the PDC Emulator in the Forest Root Domain ...................................................................................................................................................97 Disable the Windows Time Service................................................................................................98

Enable Windows Time Service Debug Logging..............................................................................99 Configuring Windows-Based Clients to Synchronize Time.............................................................99 Configure a Manual Time Source for a Selected Client Computer................................................100 Configure a Client Computer for Automatic Domain Time Synchronization...................................102 Restoring the Windows Time Service to Default Settings.............................................................103 Restore the Windows Time Service on the Local Computer to the Default Settings......................103 Administering DFS-Replicated SYSVOL......................................................................................104 Introduction to Administering DFS-Replicated SYSVOL...............................................................104 SYSVOL terminology and capitalization....................................................................................104 Using DFS Replication for replicating SYSVOL in Windows Server 2008..................................105 Requirements for using DFS Replication..................................................................................106 Key considerations for administering SYSVOL.........................................................................106 Relocating SYSVOL folders......................................................................................................108 Managing DFS-Replicated SYSVOL............................................................................................109 Changing the Quota That Is Allocated to the SYSVOL Staging Area............................................110 Change the Quota That Is Allocated to the SYSVOL Staging Folder............................................110 Relocating the SYSVOL Staging Area..........................................................................................111 Identify Replication Partners........................................................................................................112 Check the Status of the SYSVOL and Netlogon Shares...............................................................113 Verify Active Directory Replication................................................................................................114 Gather the SYSVOL Path Information..........................................................................................114 To gather the SYSVOL path information....................................................................................116 Stop the DFS Replication Service and Netlogon Service..............................................................117 Create the SYSVOL Staging Areas Folder Structure....................................................................118 Change the SYSVOL Root Path or Staging Areas Path, or Both..................................................119 See Also...................................................................................................................................120 Start the DFS Replication Service and Netlogon Service.............................................................120 Force Replication Between Domain Controllers...........................................................................121 See Also...................................................................................................................................122 Relocating SYSVOL Manually......................................................................................................122

Identify Replication Partners........................................................................................................124 Check the Status of the SYSVOL and Netlogon Shares...............................................................124 Verify Active Directory Replication................................................................................................125 Gather the SYSVOL Path Information..........................................................................................126 To gather the SYSVOL path information...................................................................................127 Stop the DFS Replication Service and Netlogon Service..............................................................129 Copy SYSVOL to a New Location................................................................................................130 Create the SYSVOL Root Junction Point.....................................................................................133 Change the SYSVOL Root Path or Staging Areas Path, or Both..................................................134 See Also...................................................................................................................................135 Change the SYSVOL Netlogon Parameters.................................................................................135 Reapply Default SYSVOL Security Settings.................................................................................136 Start the DFS Replication Service and Netlogon Service.............................................................138 Force Replication Between Domain Controllers...........................................................................139 See Also...................................................................................................................................139 Updating the SYSVOL Path.........................................................................................................139 Gather the SYSVOL Path Information..........................................................................................140 To gather the SYSVOL path information...................................................................................142 Stop the DFS Replication Service and Netlogon Service..............................................................143 Change the SYSVOL Netlogon Parameters.................................................................................144 Create the SYSVOL Root Junction Point.....................................................................................145 Start the DFS Replication Service and Netlogon Service.............................................................146 Restoring and Rebuilding SYSVOL..............................................................................................147 Identify Replication Partners........................................................................................................149 Check the Status of the SYSVOL and Netlogon Shares...............................................................149 Verify Active Directory Replication................................................................................................150 Gather the SYSVOL Path Information..........................................................................................151 To gather the SYSVOL path information...................................................................................152 Restart the Domain Controller in Directory Services Restore Mode Locally..................................154

Restarting the domain controller in DSRM locally.....................................................................155 See Also...................................................................................................................................156 Restart the Domain Controller in Directory Services Restore Mode Remotely..............................157 See Also...................................................................................................................................160 Stop the DFS Replication Service and Netlogon Service..............................................................160 Import the SYSVOL Folder Structure...........................................................................................161 See Also...................................................................................................................................164 Administering the Global Catalog.................................................................................................165 Introduction to Administering the Global Catalog..........................................................................165 Global catalog hardware requirements.....................................................................................165 Global catalog placement.........................................................................................................165 Initial global catalog replication.................................................................................................165 Global catalog readiness..........................................................................................................166 Global catalog removal.............................................................................................................166 Managing the Global Catalog.......................................................................................................167 Configuring a Global Catalog Server............................................................................................167 Determine Whether a Domain Controller Is a Global Catalog Server...........................................168 Designate a Domain Controller to Be a Global Catalog Server.....................................................168 Monitor Global Catalog Replication Progress...............................................................................169 Verify Successful Replication to a Domain Controller...................................................................170 Determining Global Catalog Readiness.......................................................................................173 Verify Global Catalog Readiness..................................................................................................173 Verifying global catalog readiness............................................................................................173 Verify Global Catalog DNS Registrations.....................................................................................174 Removing the Global Catalog......................................................................................................175 Clear the Global Catalog Setting..................................................................................................175 Monitor Global Catalog Removal in Event Viewer........................................................................176 Administering Operations Master Roles.......................................................................................177 Introduction to Administering Operations Master Roles................................................................177 Guidelines for role placement...................................................................................................178 Guidelines for role transfer.......................................................................................................181

Managing Operations Master Roles.............................................................................................182 Designating a Standby Operations Master...................................................................................183 Standby operations master computer requirements..................................................................183 Replication requirements..........................................................................................................183 Determine Whether a Domain Controller Is a Global Catalog Server...........................................184 Create a Connection Object on the Operations Master and Standby............................................184 Verify Successful Replication to a Domain Controller...................................................................185 Transferring an Operations Master Role......................................................................................188 Transferring to a standby operations master.............................................................................189 Transferring an operations master role when no standby is ready.............................................189 Install the Schema Snap-in..........................................................................................................190 Transfer the Schema Master........................................................................................................191 Transfer the Domain Naming Master...........................................................................................192 Transfer the Domain-Level Operations Master Roles...................................................................193 View the Current Operations Master Role Holders.......................................................................194 Seizing an operations master role................................................................................................195 Verify Successful Replication to a Domain Controller...................................................................196 Seize the Operations Master Role...............................................................................................199 View the Current Operations Master Role Holders.......................................................................200 Reducing the Workload on the PDC Emulator Master..................................................................201 Changing the weight for DNS service (SRV) resource records in the registry............................201 Changing the priority for DNS service (SRV) resource records in the registry...........................202 Change the Weight for DNS Service (SRV) Resource Records in the Registry............................203 Change the Priority for DNS Service (SRV) Resource Records in the Registry............................203 Administering Active Directory Backup and Recovery..................................................................204 Introduction to Administering Active Directory Backup and Recovery [lhsad_ADDS_Ops_5]_ADDS_Ops_5......................................................................................205 Backing up AD DS....................................................................................................................205 Recovering AD DS...................................................................................................................205 Additional considerations..........................................................................................................206 Managing Active Directory Backup and Recovery........................................................................207

Backing Up Active Directory Domain Services.............................................................................207 Windows Server backup tools...................................................................................................207 Windows Server backup types..................................................................................................208 Contents of Windows Server backup types...........................................................................208 Criteria for using backup types..............................................................................................209 Backup guidelines....................................................................................................................210 Scheduling regular backups......................................................................................................211 Immediate (unscheduled) backup.............................................................................................212 Backup frequency.....................................................................................................................212 Backup frequency criteria......................................................................................................213 Backup latency interval.........................................................................................................213 Known Issues for Backing Up Active Directory Domain Services..................................................215 Perform a Backup of Critical Volumes of a Domain Controller by Using the GUI (Windows Server Backup)....................................................................................................................................216 Additional considerations...................................................................................................217 Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) .................................................................................................................................................217 Additional considerations...................................................................................................218 Perform a Full Server Backup of a Domain Controller by Using the GUI (Windows Server Backup) .................................................................................................................................................218 Additional considerations...................................................................................................222 Perform a Full Server Backup of a Domain Controller by Using the Command Line (Wbadmin)...223 Additional considerations...................................................................................................223 Recovering Active Directory Domain Services..............................................................................224 Causes of disruptions...............................................................................................................224 Keys to protecting against disruptions......................................................................................225 Preventing unwanted deletions.................................................................................................225 Recovery solutions...................................................................................................................226 Solutions for configuration errors—nonauthoritative restore..................................................226 Solutions for data loss—authoritative restore........................................................................227 Recovery options with no available backup...........................................................................228 Solutions for hardware failure or file corruption......................................................................228 Recovery tasks.........................................................................................................................230 Performing Nonauthoritative Restore of Active Directory Domain Services...................................230 Nonauthoritative Restore Requirements...................................................................................231 SYSVOL restore.......................................................................................................................231 Additional references................................................................................................................232 Restart the Domain Controller in Directory Services Restore Mode Locally..................................232 Restarting the domain controller in DSRM locally.....................................................................234

See Also...................................................................................................................................235 Restart the Domain Controller in Directory Services Restore Mode Remotely..............................235 See Also...................................................................................................................................238 Restore AD DS from Backup (Nonauthoritative Restore)..............................................................238 Additional references................................................................................................................240 Verify AD DS restore....................................................................................................................240 Performing Authoritative Restore of Active Directory Objects.......................................................241 Determining objects to restore..................................................................................................242 Selecting objects to restore......................................................................................................243 Selecting application directory partitions to restore...................................................................243 Restoring group memberships after authoritative restore..........................................................244 LVR and restoration of group memberships...........................................................................244 Authoritative restore of pre-LVR group memberships and groups in different domains..........245 Files for recovering group memberships following authoritative restore.................................245 Using a global catalog server for authoritative restore...............................................................246 Recovering deletions without restoring from backup.................................................................247 Retention (merge) of new group memberships or other attributes after authoritative restore.....247 Authoritative restore procedures...............................................................................................248 Procedures for restoring after deletions have replicated........................................................249 Procedures for restoring before deletions have replicated.....................................................250 Procedures for recovering group memberships (and any other back-link attributes) in other domains.............................................................................................................................251 Additional references................................................................................................................251 Known Issues for Authoritative Restore........................................................................................252 Order of replication and dropped group memberships..............................................................252 Members added back to groups from which they were deleted.................................................253 Incorrect assignment of Exchange mailboxes...........................................................................253 Best Practices for Authoritative Restore.......................................................................................253 Restart the Domain Controller in Directory Services Restore Mode Locally..................................255 Restarting the domain controller in DSRM locally.....................................................................256 See Also...................................................................................................................................257 Restart the Domain Controller in Directory Services Restore Mode Remotely..............................257 See Also...................................................................................................................................261 Restore AD DS from Backup (Nonauthoritative Restore)..............................................................261 Additional references................................................................................................................263 Mark an Object or Objects as Authoritative..................................................................................263 Additional references................................................................................................................265

Turn Off Inbound Replication.......................................................................................................265 Additional references................................................................................................................266 Synchronize Replication with All Partners....................................................................................266 See Also...................................................................................................................................267 Run an LDIF File to Recover Back-Links......................................................................................267 Additional references................................................................................................................268 Turn on Inbound Replication........................................................................................................269 Additional references................................................................................................................269 Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects....................269 Additional references................................................................................................................270 Performing Authoritative Restore of an Application Directory Partition..........................................271 Restart the Domain Controller in Directory Services Restore Mode Remotely..............................271 See Also...................................................................................................................................275 Restart the Domain Controller in Directory Services Restore Mode Locally..................................275 Restarting the domain controller in DSRM locally.....................................................................276 See Also...................................................................................................................................277 Restore AD DS from Backup (Nonauthoritative Restore)..............................................................278 Additional references................................................................................................................279 Mark an application directory partition as authoritative.................................................................279 See Also...................................................................................................................................281 Performing a Full Server Recovery of a Domain Controller..........................................................281 Requirements for performing a full server recovery of a domain controller................................281 Performing a full server recovery of a domain controller by using the GUI................................282 Performing a full server recovery of a domain controller by using the command line.................283 Additional considerations..........................................................................................................284 Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup.....285 Restart the Domain Controller in Directory Services Restore Mode Locally..................................286 Restarting the domain controller in DSRM locally.....................................................................287 See Also...................................................................................................................................289 Restart the Domain Controller in Directory Services Restore Mode Remotely..............................289 See Also...................................................................................................................................292 Restore AD DS from Backup (Nonauthoritative Restore)..............................................................292 Additional references................................................................................................................294 Verify AD DS restore....................................................................................................................294

Restoring a Domain Controller Through Reinstallation.................................................................295 Clean Up Server Metadata...........................................................................................................297 See Also...................................................................................................................................299 Delete a Server Object from a Site...............................................................................................300 See Also...................................................................................................................................300 Verify DNS Registration and TCP/IP Connectivity........................................................................301 Verify the Availability of the Operations Masters...........................................................................301 Install an Additional Domain Controller by Using the Windows Interface......................................303 See Also...................................................................................................................................305 Verifying Active Directory Installation............................................................................................305 Administering Intersite Replication...............................................................................................306 Introduction to Administering Intersite Replication........................................................................306 Optimizing replication between sites.........................................................................................307 Effects of site link bridging.....................................................................................................307 Effects of disabling site link bridging......................................................................................307 Optimizing domain controller location.......................................................................................308 Finding the next closest site..................................................................................................308 Forcing domain controller rediscovery...................................................................................309 Improving the logon experience in branch sites........................................................................309 See Also...................................................................................................................................310 Managing Intersite Replication.....................................................................................................310 Adding a New Site.......................................................................................................................310 Create a Site Object and Add it to an Existing Site Link................................................................311 See Also...................................................................................................................................312 Create a Subnet Object or Objects and Associate them with a Site..............................................312 Associate an Existing Subnet Object with a Site..........................................................................313 Create a Site Link Object and Add the Appropriate Sites..............................................................313 Remove a Site from a Site Link....................................................................................................314 Linking Sites for Replication.........................................................................................................314 Creating site links.....................................................................................................................315 Selecting bridgehead servers...................................................................................................315 Create a Site Link Object and Add the Appropriate Sites..............................................................316

Determine the ISTG Role Owner for a Site..................................................................................317 Generate the Replication Topology on the ISTG..........................................................................317 Designate a Server as a Preferred Bridgehead Server.................................................................318 Changing Site Link Properties......................................................................................................319 Configure the Site Link Schedule to Identify Times During Which Intersite Replication Can Occur .................................................................................................................................................319 Configure the Site Link Interval to Identify How Often Replication Polling Can Occur During the Schedule Window.....................................................................................................................320 Configure the Site Link Cost to Establish a Priority for Replication Routing..................................321 Determine the ISTG Role Owner for a Site..................................................................................321 Generate the Replication Topology on the ISTG..........................................................................322 Enabling Clients to Locate the Next Closest Domain Controller...................................................323 Enable Clients to Locate a Domain Controller in the Next Closest Site.........................................325 Moving a Domain Controller to a Different Site.............................................................................326 TCP/IP settings........................................................................................................................326 DNS settings............................................................................................................................326 Preferred bridgehead server status...........................................................................................327 Change the Static IP Address of a Domain Controller..................................................................328 Update the IP Address for a DNS Delegation...............................................................................329 Update the IP Address for a DNS Forwarder................................................................................330 Verify That an IP Address Maps to a Subnet and Determine the Site Association.........................331 See Also...................................................................................................................................332 Determine Whether a Server is a Preferred Bridgehead Server...................................................332 See Also...................................................................................................................................332 View the List of All Preferred Bridgehead Servers........................................................................333 See Also...................................................................................................................................333 Configure a Server to Not Be a Preferred Bridgehead Server......................................................333 See Also...................................................................................................................................334 Move a Server Object to a New Site............................................................................................334 See Also...................................................................................................................................335 Enabling Universal Group Membership Caching in a Site............................................................335

Enable Universal Group Membership Caching in a Site...............................................................336 Forcing Replication......................................................................................................................336 Forcing replication of all directory updates over a connection...................................................337 Forcing replication of configuration updates..............................................................................337 Force Replication Between Domain Controllers...........................................................................338 See Also...................................................................................................................................339 Update a Server with Configuration Changes..............................................................................339 Synchronize Replication with All Partners....................................................................................340 See Also...................................................................................................................................341 Verify Successful Replication to a Domain Controller...................................................................341 Removing a Site..........................................................................................................................345 Delete a Manual Connection Object.............................................................................................346 Determine Whether a Server Object Has Child Objects...............................................................347 Delete a Server Object from a Site...............................................................................................348 See Also...................................................................................................................................349 Delete a Site Link object..............................................................................................................349 Associate an Existing Subnet Object with a Site..........................................................................349 Delete a Site object......................................................................................................................350 See Also...................................................................................................................................350 Determine the ISTG Role Owner for a Site..................................................................................350 Generate the Replication Topology on the ISTG..........................................................................351 Administering the Active Directory Database................................................................................352 Introduction to Administering the Active Directory Database [lhsad]_ADDS_Ops_7.....................352 Database management conditions...........................................................................................352 Disk space monitoring recommendations.................................................................................353 Database defragmentation.......................................................................................................353 Restartable AD DS...................................................................................................................353 See Also...................................................................................................................................354 Managing the Active Directory Database.....................................................................................354 Relocating the Active Directory Database Files............................................................................354 Disk space requirements for relocating Active Directory database files.....................................355 Determine the Database Size and Location Online......................................................................357

See Also...................................................................................................................................358 Determine the Database Size and Location Offline......................................................................358 See Also...................................................................................................................................359 Compare the Size of the Directory Database Files to the Volume Size.........................................359 Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) .................................................................................................................................................360 Additional considerations...................................................................................................361 Move the Directory Database and Log Files to a Local Drive.......................................................361 See Also...................................................................................................................................364 Copy the Directory Database and Log Files to a Remote Share...................................................364 See Also...................................................................................................................................367 Returning Unused Disk Space from the Active Directory Database to the File System.................367 Change the Garbage Collection Logging Level to 1.....................................................................369 See Also...................................................................................................................................369 Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) .................................................................................................................................................370 Additional considerations...................................................................................................370 Compact the Directory DatabaseFfile (Offline Defragmentation)..................................................371 See Also...................................................................................................................................374 If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup...............374 Administering Domain Controllers................................................................................................375 Additional references................................................................................................................376 Introduction to Administering Domain Controllers.........................................................................376 Installing Remote Server Administration Tools..........................................................................376 Installing and removing AD DS.................................................................................................376 Adding domain controllers.....................................................................................................377 Removing domain controllers................................................................................................377 Renaming domain controllers...................................................................................................377 Adding domain controllers to branch sites................................................................................377 Installing from media.............................................................................................................378 Shipping installed domain controllers to branch sites.............................................................379 Managing Domain Controllers......................................................................................................379 Installing Remote Server Administration Tools for AD DS.............................................................381 Installing Active Directory Domain Services Tools on a member server that is running Windows Server 2008...........................................................................................................381

Installing Active Directory Domain Services Tools on a computer that is running Windows Vista with SP1...............................................................................................................................382 Managing Antivirus Software on Active Directory Domain Controllers...........................................382 Guidelines for managing antivirus software on Active Directory domain controllers...................383 Files to exclude from scanning.................................................................................................384 Preparing for Active Directory Installation.....................................................................................386 DNS configuration....................................................................................................................386 Site placement.........................................................................................................................386 Domain connectivity.................................................................................................................387 Verify DNS Infrastructure and Registrations.................................................................................388 Verify That an IP Address Maps to a Subnet and Determine the Site Association.........................390 See Also...................................................................................................................................390 Verify the Availability of the Operations Masters...........................................................................391 Installing a Domain Controller in an Existing Domain...................................................................392 See Also...................................................................................................................................393 Installing an Additional Domain Controller by Using the Windows Interface..................................393 See Also...................................................................................................................................394 Install an Additional Domain Controller by Using the Windows Interface......................................394 See Also...................................................................................................................................396 Installing an Additional Domain Controller by Using IFM..............................................................397 See Also...................................................................................................................................399 Create Installation Media by Using Ntdsutil..................................................................................399 See Also...................................................................................................................................400 Install an Additional Domain Controller by Using Installation Media..............................................400 See Also...................................................................................................................................401 Installing an Additional Domain Controller by Using Unattend Parameters...................................401 See Also...................................................................................................................................402 Create an Answer File for Unattended Domain Controller Installation...........................................402 See Also...................................................................................................................................404 Install an Additional Domain Controller by Using an Answer File..................................................404 See Also...................................................................................................................................405 Install an Additional Domain Controller by Using Unattend Parameters from the Command Line. 405 Verifying Active Directory Installation............................................................................................406

Verify That an IP Address Maps to a Subnet and Determine the Site Association.........................407 See Also...................................................................................................................................408 Configure DNS Server Forwarders..............................................................................................408 Verifying DNS Configuration........................................................................................................409 Verify DNS Server Configuration for a Domain Controller.............................................................409 See Also...................................................................................................................................410 Verify DNS Client Settings...........................................................................................................410 See Also...................................................................................................................................411 Check the Status of the SYSVOL and Netlogon Shares...............................................................411 Verify Active Directory Replication................................................................................................412 Verify a Domain Computer Account for a New Domain Controller................................................413 Adding Domain Controllers in Remote Sites................................................................................413 Best Practices for Adding Domain Controllers in Remote Sites....................................................414 Best practices for using IFM to install AD DS in the remote site................................................415 Best practices for installing domain controllers before you ship them to a remote site...............417 See Also...................................................................................................................................419 Known Issues for Adding Domain Controllers in Remote Sites.....................................................419 SYSVOL replication..................................................................................................................419 Using IFM to install a domain controller in a remote site...........................................................420 Advantages of using IFM to install a domain controller in a remote site.................................420 Issues with using IFM to install a domain controller in a remote site......................................421 Installing domain controllers before shipping them to the remote site........................................422 Advantages of installing domain controllers before shipping them to the remote site.............422 Issues with installing domain controllers before shipping them to the remote site..................422 Maintaining directory consistency when you disconnect a domain controller.........................423 Protection against lingering object replication....................................................................424 Availability of operations masters.......................................................................................424 Up to dateness of active directory replication.....................................................................425 SYSVOL consistency.........................................................................................................425 See Also...................................................................................................................................425 Preparing a Server Computer for Shipping and Installation from Media........................................425 Determining the volume for installation media...........................................................................426 Enabling Remote Desktop........................................................................................................427 Including application directory partitions...................................................................................427 See Also...................................................................................................................................428 Enable Remote Desktop..............................................................................................................428

Create a Remote Desktop Connection.........................................................................................429 See Also...................................................................................................................................430 Install an Additional Domain Controller by Using Installation Media..............................................430 See Also...................................................................................................................................431 Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection..................431 See Also...................................................................................................................................433 Determine the Tombstone Lifetime for the Forest.........................................................................433 Enable Strict Replication Consistency..........................................................................................434 Synchronize Replication with All Partners....................................................................................435 See Also...................................................................................................................................436 Reconnecting a Domain Controller After a Long-Term Disconnection...........................................436 Reconnecting an outdated domain controller............................................................................437 Updating SYSVOL....................................................................................................................437 See Also...................................................................................................................................438 Determine the Tombstone Lifetime for the Forest.........................................................................439 Move a Server Object to a New Site............................................................................................439 See Also...................................................................................................................................440 Determine When Intersite Replication Is Scheduled to Begin.......................................................440 Use Repadmin to Remove Lingering Objects...............................................................................441 Verify Successful Replication to a Domain Controller...................................................................443 Renaming a Domain Controller....................................................................................................447 Rename a Domain Controller Using System Properties...............................................................448 See Also...................................................................................................................................448 Rename a Domain Controller Using Netdom...............................................................................448 See Also...................................................................................................................................450 Update the FRS or DFS Replication Member Object....................................................................451 Decommissioning a Domain Controller........................................................................................452 Removing a domain or a forest.................................................................................................452 Protecting EFS-encrypted files.................................................................................................452 See Also...................................................................................................................................455 Verify DNS Registration and TCP/IP Connectivity........................................................................455 View the Current Operations Master Role Holders.......................................................................455

Transfer the Schema Master........................................................................................................456 Transfer the Domain Naming Master...........................................................................................457 Transfer the Domain-Level Operations Master Roles...................................................................458 Determine Whether a Domain Controller Is a Global Catalog Server...........................................460 Verify the Availability of the Operations Masters...........................................................................460 Back Up a Certificate With Its Private Key....................................................................................461 Removing a Windows Server 2008 Domain Controller from a Domain.........................................463 Removing a Windows Server 2008 domain controller by using the Windows interface.............463 Removing a Windows Server 2008 domain controller by using an answer file..........................464 Removing a Windows Server 2008 domain controller by entering unattended installation parameters at the command line...........................................................................................465 Import a Certificate......................................................................................................................465 Determine Whether a Server Object Has Child Objects...............................................................466 Delete a Server Object from a Site...............................................................................................467 See Also...................................................................................................................................468 Add the Certificates Snap-in to an MMC......................................................................................468 Adding the Certificates Snap-in to an MMC..............................................................................468 Forcing the Removal of a Domain Controller................................................................................470 Identify Replication Partners........................................................................................................471 Force Domain Controller Removal...............................................................................................472 See Also...................................................................................................................................473 Clean Up Server Metadata...........................................................................................................473 See Also...................................................................................................................................476 Administering Active Directory Domain Rename..........................................................................476 In this guide..............................................................................................................................476 Introduction to Administering Active Directory Domain Rename...................................................476 Domain rename requirements..................................................................................................477 Managing Active Directory Domain Rename................................................................................478 Preparing for the Domain Rename Operation..............................................................................478 Adjust Forest Functional Level.....................................................................................................479 Setting forest functional level to Windows Server 2003 or Windows Server 2008.....................479

Create Necessary Shortcut Trust Relationships...........................................................................480 Types of trust relationships.......................................................................................................480 Precreating parent-child trust relationships for a restructured forest..........................................481 Precreating a parent-child trust relationship...........................................................................481 Pre-creating multiple parent-child trust relationships.............................................................481 Precreating a tree-root trust relationship with the forest root domain.....................................483 Creating shortcut trust relationships......................................................................................483 Prepare DNS Zones....................................................................................................................484 Redirect Special Folders to a Standalone DFSN..........................................................................485 Relocate Roaming User Profiles to a Standalone DFSN..............................................................485 Configure Member Computers for Host Name Changes..............................................................486 Conditions for automatic computer name change.....................................................................486 Replication effects of renaming large numbers of computers....................................................487 Using Group Policy to apply the new primary DNS suffix..........................................................488 Apply the new primary DNS suffix before renaming domains.................................................488 Apply Group Policy in stages to avoid significant replication..................................................488 Configuration required before the application of Group Policy...............................................489 Configuring member computers for host name changes in large deployments..........................490 Determine the primary DNS Suffix configuration....................................................................491 Determine whether Group Policy controls the primary DNS suffix..........................................491 Configure the domain to allow a primary DNS suffix that does not match the domain name. .492 Apply Group Policy to set the primary DNS suffix..................................................................493 Prepare Certification Authorities...................................................................................................494 Exchange-Specific Steps: Prepare a Domain that Contains Exchange.........................................495 Performing the Domain Rename Operation.................................................................................496 Set Up the Control Station...........................................................................................................497 Freeze the Forest Configuration...................................................................................................498 Back Up All Domain Controllers...................................................................................................499 Generate the Current Forest Description.....................................................................................499 Specify the New Forest Description.............................................................................................501 Renaming application directory partitions.................................................................................504 DNS data.................................................................................................................................505 TAPI data.................................................................................................................................506 Specifying the source domain controllers..................................................................................506 Reviewing the new forest description........................................................................................506

Generate Domain Rename Instructions.......................................................................................507 Push Domain Rename Instructions to All Domain Controllers and Verify DNS Readiness............510 Pushing domain rename instructions to all domain controllers..................................................510 Verifying DNS readiness...........................................................................................................512 Verify Readiness of Domain Controllers.......................................................................................514 Run Domain Rename Instructions...............................................................................................516 Exchange-Specific Steps: Update the Exchange Configuration and Restart Exchange Servers...519 Unfreeze the Forest Configuration...............................................................................................519 Re-establish External Trusts........................................................................................................520 Fix Group Policy Objects and Links.............................................................................................521 Completing the Domain Rename Operation.................................................................................524 Verify Certificate Security.............................................................................................................524 Preparing URLs for CRL distribution point and Authority Information Access (AIA) extensions after a domain rename..................................................................................................................524 Verifying the use of UPNs.........................................................................................................525 Enabling certificate enrollment in a renamed domain................................................................526 Verifying the validity of CRL distribution point and AIA extensions.............................................528 Renewing subordinate and issuing CA certificates....................................................................529 Publish new CRLs....................................................................................................................529 Updating domain controller certificates.....................................................................................529 Changing the user identity for the NDES add-on......................................................................530 Perform Miscellaneous Tasks.......................................................................................................530 Back Up Domain Controllers........................................................................................................532 Restart Member Computers.........................................................................................................533 Exchange-Specific Steps: Verify the Exchange Rename and Update Active Directory Connector 534 Perform Attribute Cleanup............................................................................................................534 Rename Domain Controllers........................................................................................................535 Additional Resources for the Domain Rename Operation............................................................536 Appendix A: Command-Line Syntax for the Rendom Tool............................................................536 Appendix B: Command-Line Syntax for the Gpfixup Tool.............................................................541 Appendix C: Checklists for the Domain Rename Operation.........................................................543 Satisfying domain rename requirements...................................................................................544

Preparing for the domain rename operation..............................................................................546 Performing the domain rename operation.................................................................................548 Completing the domain rename operation................................................................................549 Appendix D: Worksheets for the Domain Rename Operation.......................................................550 Worksheet 1: Domain Name Change Information.....................................................................550 Worksheet 2: Trust Information.................................................................................................550 Worksheet 3: DNS Zone Information........................................................................................551 Worksheet 4: DFSN, Folder Redirection, and Roaming Profiles................................................551 Worksheet 5: Domain Controller Information............................................................................552 Worksheet 6: Domain Rename Execution Readiness...............................................................552 Worksheet 7: Certification Authority (CA) Information...............................................................553 Additional Resources...................................................................................................................553 Active Directory Domain Services Operations Guide - cover........................................................554 Section Heading.......................................................................................................................554 Subsection Heading..............................................................................................................554

Active Directory Domain Services Operations Guide
This operations guide provides administering and management information for Active Directory® Domain Services (AD DS) directory service technologies in the Windows Server® 2008 operating system. In this guide • • New in This Guide Administering Active Directory Domain Services

Acknowledgments Produced by: Microsoft Windows Server Directory and Access Services (DAS) IT Pro Content Team Writers: Mary Hillman, Gayana Bagdasaryan Editor: Jim Becker Technical reviewers: Umit Akkus, David Beach, Arren Conner, Gregoire Guetat, Xin He, Kurt Hudson, Jessie Li, Herbert Mauerer, Joe Patterson, Ned Pyle, Wakkas Rafiq, Ryan Sizemore, Ingolfur Arnar Strangeland, Mahesh Unnikrishnan

New in This Guide
This is the first release of the operations guide for Active Directory Domain Services (AD DS) in Windows Server 2008. This guide will be updated periodically to incorporate new information, updates, customer feedback, and corrections. For Windows Server 2008, this operations guide contains the section Administering Active Directory Domain Rename, which is not included in the Active Directory Operations Guide for Windows Server 2003.

Administering Active Directory Domain Services
This guide provides information about administering components of Active Directory Domain Services (AD DS) in Windows Server 2008. The information includes detailed procedures for managing domain controllers, sites, trusts, and other components of AD DS. In this guide • • Introduction to Administering Active Directory Domain Services Administering Domain and Forest Trusts 24

• • • • • • • • • •

Administering the Windows Time Service Administering DFS-Replicated SYSVOL Administering the Global Catalog Administering Operations Master Roles Administering Active Directory Backup and Recovery Administering Intersite Replication Administering the Active Directory Database Administering Domain Controllers Administering Active Directory Domain Rename Additional Resources

Introduction to Administering Active Directory Domain Services
This guide explains how to administer Active Directory Domain Services (AD DS) in Windows Server 2008. These activities are part of the operations 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
Use this guide when: • You want to manage common Active Directory problems that are associated with misconfiguration. • You want to configure AD DS to increase network availability. This guide assumes a basic understanding of what AD DS is, how it works, and why your organization uses it to access, manage, and secure shared resources across your network. It also assumes a thorough understanding of how AD DS 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 2008. It includes information that is relevant to different roles in an IT organization, including IT operations managers, administrators, and operators. This information includes management-level knowledge about AD DS and administrator-level information about the IT processes that are required to operate it. This guide contains detailed procedures that are designed for operators (or designated users) 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 Microsoft Management Console (MMC) and MMC snap-ins. Operators must also know how to start administrative programs and 25

access the command line. If operators are not familiar with AD DS, it might be necessary for IT planners, managers, or administrators to review the relevant operations in this guide and provide the operators with the parameters or data that they must enter when they perform the operations.

How to use this guide
This guide includes the following types of topics: • Objectives are high-level goals for administering AD DS. Each objective consists of one or more high-level tasks that describe how the objective is accomplished. In this guide, "Managing the Windows Time Service" is an example of an objective. • Tasks contain groups of procedures for achieving the goals of an objective. In this guide, "Configuring a time source for the forest" is an example of a task. • Procedures provide step-by-step instructions for completing tasks. In this guide, "Configure a domain controller in the parent domain as a reliable time source" is an example of a procedure topic. If you are an IT manager who is delegating tasks to operators in your organization: • Read through the objectives and tasks to determine how to delegate permissions. • Determine whether you need to install tools before operators perform the procedures for each task. Before you assign tasks to individual operators, ensure that all the tools are installed where operators can use them. • When necessary, create “tear sheets” for each task that operators perform in your organization. Cut and paste the task and its related procedures into a separate document. Then you can either print this document or store it online.

Administering Domain and Forest Trusts
This guide provides administrators with step-by-step instructions for managing and securing Windows Server 2008 domain and forest trusts in Active Directory Domain Services (AD DS). 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 also determines how far network communications extend within a forest or across forests. In this guide • • • • • Introduction to Administering Domain and Forest Trusts Best Practices for Administering Domain and Forest Trusts Managing Domain and Forest Trusts Securing Domain and Forest Trusts Appendix: New Trust Wizard Pages

26

Introduction to Administering Domain and Forest Trusts
By using Windows Server 2008 domain and forest trusts, service administrators can create or extend collaborative relationships between two or more domains or forests. Windows Server 2008 domains and forests can also trust Kerberos realms and other Windows Server 2008 forests, as well as Windows Server 2003 domains, Microsoft® Windows® 2000 Server domains, and Microsoft Windows NT® Server 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 Domain Services (AD DS) is organized and whether different versions of Windows coexist on the network.

Best Practices for Administering Domain and Forest Trusts
The following best practices increase availability, ensure trouble-free operations, or ease administration when you use them to administer domain and forest trusts: • Optimize authentication speed in multidomain forests. 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" in Understanding When to Create a Shortcut Trust (http://go.microsoft.com/fwlink/?LinkID=107061). • Keep a current list of trust relationships for future reference. 27

You can use the Nltest.exe tool to display and record a list of these trusts. For more information, see Nltest Overview (http://go.microsoft.com/fwlink/?LinkID=93567). • Back up domain controllers. Perform regular backups of domain controllers to preserve all trust relationships within a particular domain.

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 make it possible for your organization to communicate effectively with users or resources in other locations. 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 2008, there are four trust types that must be created manually. External trusts, realm trusts, and forest trusts help provide interoperability with realms or with domains outside your forest. Shortcut trusts optimize access to resources and logons that are made between domain trees in the same forest. This section includes the following tasks for creating domain and forest trusts: • • • • 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 members of the Authenticated Users group. Before you use the procedures in these tasks, review the issues in Known Issues for Creating Domain and Forest Trusts.

28

New Trust Wizard terminology
You create trusts in Windows Server 2008 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 one-way, outgoing trust to domain B, this action 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. 29

• 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 Domain Services (AD DS). 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 2008: • You cannot delegate the creation of trusts to any user who is not a member of the Domain Admins group or the Enterprise Admins group. 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. • 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 (that is, you are 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 the Active Directory Domains and Trusts snap-in 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 NetBIOS name 30

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 may not appear in the New Trust Wizard. This issue typically occurs when one or both of the Windows Server 2008 forests are not set to the Windows Server 2003 forest functional level or higher. For more information about forest functional levels, see Active Directory Functional Levels Technical Reference (http://go.microsoft.com/fwlink/?LinkId=111466). • You cannot create a trust relationship with a Microsoft Windows Small Business Server 2003 (Windows SBS) domain. For information about Windows SBS software, see Introduction to Windows Small Business Server 2003 for Enterprise IT Pros (http://go.microsoft.com/fwlink/?LinkId=121891).

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 Domain Services (AD DS) forest that is not joined by a forest trust. For example, if you have a Windows Server 2008–based domain whose users want to gain access to resources that are stored in a Windows NT–based domain, you must create a trust relationship in which the Windows NT–based domain trusts the users from the Windows Server 2008–based domain. In this case, the Windows NT–based domain is the trusting domain, and the Windows Server 2008–based domain is the trusted domain. • You can create an external trust between two Windows Server 2003–based or Windows Server 2008–based domains, between a Windows Server 2008–based domain and a Windows Server 2003–based domain, or between a Windows Server 2003–based domain or Windows Server 2008–based domain and a Windows NT–based domain. External trusts cannot be extended implicitly to a third domain. • To create an external trust between domains in different forests, the forest functional level for both of the forests must be set to either Windows Server 2003 or Windows Server 2008. For more information about functional levels, see Active Directory Functional Levels Technical Reference (http://go.microsoft.com/fwlink/?LinkId=111466). • To create an external 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 that server the root DNS 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.

31

• If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are running Windows Server 2003, 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 Windows Server 2008 or Windows Server 2003 , 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 AD DS, see DNS Support for Active Directory Technical Reference (http://go.microsoft.com/fwlink/?LinkID=106660). For more information about external trusts, see How Domain and Forest Trusts Work (http://go.microsoft.com/fwlink/?LinkId=111481). Note Trusts that are created between Windows NT 4.0 domains and AD DS domains are one way and nontransitive, and they require 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 Overview (http://go.microsoft.com/fwlink/?LinkId=111537). 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 "Sides of Trust" in Appendix: New Trust Wizard Pages. To complete the task of creating an external trust, you can perform 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

32

Create a One-Way, Incoming, External Trust for One Side of the Trust
You can use this procedure to create 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 outgoing 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create an external trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 NetBIOS name) of the external 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 "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 "Sides of Trust" in Appendix: New Trust Wizard Pages. 33

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 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, 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
You can use this procedure to create both sides of a one-way, incoming, external trust. You must 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create an external trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about 34

using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 NetBIOS name) of the external 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 "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 "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.

35

Create a One-Way, Outgoing, External Trust for One Side of the Trust
You can use this procedure to create 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 incoming 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create an external trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 NetBIOS name) of the external 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 "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 "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Outgoing Trust Authentication Level page, do one of the following, and then 36

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 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 that 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 password that was used during this procedure.

Create a One-Way, Outgoing, External Trust for Both Sides of the Trust
You can use this procedure to create both sides of a one-way, outgoing, external trust. You must 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create an external trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). 37

Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 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 "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 "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 that 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.

38

Create a Two-Way, External Trust for One Side of the Trust
You can use this procedure to create 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create an external trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 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 "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 "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. 39

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 that 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
You can use this procedure to create both sides of a two-way, external trust. You must 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 Two-Way, 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 two-way, 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create an external trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 40

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 for which you want to establish a trust, 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 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 "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 "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 that 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. 41

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 occur 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 (http://go.microsoft.com/fwlink/?LinkID=111481). 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 Overview (http://go.microsoft.com/fwlink/?LinkId=111537). 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. To complete the task of creating a shortcut trust, perform 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

42

Create a One-Way, Incoming, Shortcut Trust for One Side of the Trust
You can use this procedure to create 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 outgoing 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a shortcut trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 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 "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 "Sides of Trust" in Appendix: New Trust Wizard Pages. 8. On the Trust Password page, type the trust password twice, and then click Next. 43

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
You can use this procedure to create both sides of a one-way, incoming, shortcut trust. You must 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a shortcut trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477.

44

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 for which you want to establish a trust, 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 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 "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 "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
You can use this procedure to create 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 incoming 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 45

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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a shortcut trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 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 "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 "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 that 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.

46

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
You can this procedure to create both sides of a one-way, outgoing, shortcut trust. You must 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a shortcut trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 NetBIOS name) of the domain, and then click Next. 5. On the Trust Type page, click External trust, and then click Next. 47

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 "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 "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 that 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
You can use this procedure to create 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a shortcut trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about 48

using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 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 "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 "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 that 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 password that was used during this procedure.

49

Create a Two-Way, Shortcut Trust for Both Sides of the Trust
You can use this procedure to create both sides of a two-way, shortcut trust. You must 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 Two-Way, 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 the Active Directory Domains and Trusts snap-in 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 Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a trust, 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 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 "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 "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. 50

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 that 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 2008 forest, you can link two disjoined Windows Server 2008 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 (http://go.microsoft.com/fwlink/?LinkID=111481). Task requirements The following are required to create forest trusts successfully: • You can create a forest trust between two Windows Server 2003 forests, between two Windows Server 2008 forests, or between a Windows Server 2003 forest and a Windows Server 2008 forest. Forest trusts cannot be extended implicitly to a third forest. • To create a forest trust, the forest functional level for both of the forests that are involved in the trust relationship must be set to Windows Server 2003. For more information about functional levels, see the Active Directory Functional Levels Technical Reference (http://go.microsoft.com/fwlink/?LinkID=111466). • 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 DNS 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 Windows Server 2003, configure DNS conditional forwarders in each DNS namespace to route queries for names in the other namespace.

51

• If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are not running Windows Server 2008 or Windows Server 2003, 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 Domain Services (AD DS), see the DNS Support for Active Directory Technical Reference (http://go.microsoft.com/fwlink/?LinkID=106660). 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 using the Netdom command-line tool to create a forest trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). 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 "Sides of Trust" in Appendix: New Trust Wizard Pages. To create a forest trust, perform 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
You can use this procedure to create 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 outgoing 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.

52

A one-way, incoming, forest trust allows users in your Windows Server 2008 forest or 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 2008 forest or 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 the Active Directory Domains and Trusts snap-in 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 Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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 (http://go.microsoft.com/fwlink/?LinkID=111481). 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 forest root domain of the forest for which you want to establish an incoming forest trust, 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 of the forest root domain of the other forest, 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 "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 "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 53

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 his or her administrative credentials and the exact same trust password that was used during this procedure.

Create a One-Way, Incoming, Forest Trust for Both Sides of the Trust
You can use this procedure to create both sides of a one-way, incoming, forest trust. You must 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 2008 forest or 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 2008 forest or 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a forest trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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 (http://go.microsoft.com/fwlink/?LinkID=111481). 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 forest root domain of the forest for which you want to establish an incoming forest trust, and then click Properties. 54

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 of the forest root domain of the other forest, 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 "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 "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
You can use this procedure to create 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 incoming 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 2008 forest or Windows Server 2003 forest (the forest that you are logged on to at the time that you run the New 55

Trust Wizard) to be accessed by users in another Windows Server 2008 forest or 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a forest trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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 (http://go.microsoft.com/fwlink/?LinkID=111481). 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 forest root domain for which you want to establish an outgoing forest trust, 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 of the forest root domain of the other forest, 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 "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 "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 56

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 One-Way, 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
You can use this procedure to create both sides of a one-way, outgoing, forest trust. You must have administrative credentials for your forest as well as for the reciprocal forest. If you have administrative credentials only for your forest root 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 2008 forest or 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 2008 forest or 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a forest trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. For more information about the Incoming Forest Trust Builders group, see How Domain and Forest Trusts Work (http://go.microsoft.com/fwlink/? LinkID=111481). To create a one-way, outgoing, forest trust for both sides of the trust 1. Open Active Directory Domains and Trusts. 57

2. In the console tree, right-click the forest root domain of the forest for which you want to establish an outgoing forest trust, 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 of the forest root domain of the other forest, 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 "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 "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 that 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
You can use this procedure to create 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 incoming side of the trust. If you have administrative credentials for both forests that are involved in the trust, you can use the procedure

58

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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a forest trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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 (http://go.microsoft.com/fwlink/?LinkID=111481). 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 forest root domain of the forest for which you want to establish a two-way forest trust, 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 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 "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 "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 59

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 forest administrator in the 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, Forest Trust for Both Sides of the Trust
You can this procedure to create both sides of a two-way, forest trust You must 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 Two-Way, 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 the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a forest trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.) 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 (http://go.microsoft.com/fwlink/?LinkID=111481).

60

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 forest root domain for which you want to establish a trust, 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 of the forest root domain of the other forest, 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 "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 "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. 61

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 nonWindows Kerberos realms in your organization. You can create the trust when you are logged 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 (http://go.microsoft.com/fwlink/?LinkID=111481). 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 Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Note The New Trust Wizard in the Active Directory Domains and Trusts snap-in 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. To create a realm trust, perform 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 2008 domain or 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 a Kerberos realm. For example, if you are the administrator of the sales.wingtiptoys.com domain and users in that domain need access to resources in the PRODUCTS.TAILSPINTOYS.com Kerberos realm, you can use this procedure to establish a relationship so that users in the sales.wingtiptoys.com domain have access to resources in the Kerberos realm.

62

Note Kerberos realm names require uppercase characters. You can create a realm trust by using the New Trust Wizard in the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a realm trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a realm trust, 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 of the Kerberos realm in uppercase characters, 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 "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 Kerberos realm must complete the trust, using his or her administrative credentials and the exact same trust password that was used during this procedure.

63

Create a One-Way, Outgoing, Realm Trust
A one-way, outgoing realm trust allows resources in your Windows Server 2008 domain or 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 PRODUCTS.TAILSPINTOYS.com 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. Note Kerberos realm names require uppercase characters. You can create this realm trust by using the New Trust Wizard in the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about using the Netdom command-line tool to create a realm trust, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Account Operators, Domain Admins, or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create a one-way, outgoing, realm trust 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the domain for which you want to establish a realm trust, 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 of the Kerberos realm in uppercase characters, 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 "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. 64

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 Windows Server 2008 domain or Windows Server 2003 domain (the domain that you are logged on to at the time that you run the New Trust Wizard) and users in a specified Kerberos realm to access resources in either the domain or the Kerberos realm. For example, if users in the sales.wingtiptoys.com domain need access to resources in the PRODUCTS.TAILSPINTOYS.com Kerberos realm, and the realm users also need access to resources in the domain, you can use this procedure to establish a two-way trust relationship that allows users in both the realm and the domain to have access to resources in both places. Note Kerberos realm names require uppercase characters. You can create this realm trust by using the New Trust Wizard in the Active Directory Domains and Trusts snap-in 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 Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. 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 for which you want to establish a realm trust, 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 of the Kerberos realm, 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. 65

For more information about the selections that are available on the Direction of Trust page, see "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 Kerberos 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. This section includes the following tasks for removing a manually created trust: • • Validating and Removing Trusts Modifying Name Suffix Routing Settings

Validating and Removing Trusts
After a trust has been established, you might need to verify that it is working as designed—or that communications over the trust are working—by using Active Directory Domain Services (AD DS) tools to validate connectivity over the trust. It might 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 validate and remove trusts, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). To complete this task, perform the following procedures: • • Validate a Trust Remove a Manually Created Trust

66

Validate a Trust
You can validate all trusts that are made between domains, but you cannot validate realm trusts. You can use this procedure to validate a trust by using the New Trust Wizard in the Active Directory Domains and Trusts snap-in 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 Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477.

Validating a trust
• • Using the Windows interface Using the command line

To validate a trust 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/outgoing trust. If you click this option, we recommend that you repeat this procedure for the reciprocal domain. • Click Yes, validate the incoming/outgoing trust. If you click this option, you must type a user account and password with administrative credentials for the reciprocal domain. To validate a trust using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /verify

67

Value

Description

<TrustingDomainName>

Specifies the Domain Name System (DNS) name (or NetBIOS name) of the trusting domain in the trust that is being created.
Description

Value

<TrustedDomainName>

Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created.

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 use this procedure to remove a manually created trust by using the New Trust Wizard in the Active Directory Domains and Trusts snap-in or by using the Netdom command-line tool. For more information about the Netdom command-line tool, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477.

Removing a manually created trust
• • Using the Windows interface Using a command prompt

To remove a manually created trust 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: 68



Click No, remove the trust from the local domain only.

If you click this option, we recommend 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. To remove a manually created trust using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
netdom trust <TrustingDomainName> /d:<TrustedDomainName> /remove /UserD:<User> /PasswordD:*

Parameter

Description

<TrustingDomainName>

The Domain Name System (DNS) name (or 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 account name of the user authorized to create the trust.

<TrustedDomainName>

<User>

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 for managing how authentication requests are routed across Windows Server 2008 forests and 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. 69

All names that are subordinate to unique name suffixes are routed implicitly. For example, if your forest uses fabrikam.com as a unique name suffix, authentication requests for all child domains of fabrikam.com (childDomain.fabrikam.com) will be routed because the child domains are part of the fabrikam.com name suffix. Child names are displayed in the Active Directory Domains and Trusts snap-in. If you want to exclude members of a child domain from authenticating in the specified forest, you can disable name suffix routing for that name. You can also disable routing for the forest name itself, if necessary. For more information about name suffix routing, see Routing name suffixes across forests (http://go.microsoft.com/fwlink/?LinkId=111725). Note You cannot enable a name suffix that is the same as another name in the routing list. If the conflict is with a local UPN name suffix, you must remove the local UPN name suffix from the list 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 using the Netdom command-line tool to modify name suffix routing, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). To complete this task, you can perform the following procedures: • • • Modify Routing for a Forest Name Suffix Modify Routing for a Subordinate Name Suffix Exclude Name Suffixes from Routing to a Forest

Modify Routing for a Forest Name Suffix
If you want to prevent or allow authentication requests for all name suffixes that are identified by a forest trust (*.forestname.com) from being routed to a forest, you can use this procedure to enable or disable routing for the forest name. You can enable or disable routing for a name suffix by using the Active Directory Domains and Trusts snap-in. You can also use the Netdom command-line tool. For more information about using the Netdom command-line tool to modify name suffix routing settings, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Notes • When you disable a name suffix, the Domain Name System (DNS) name and all child names of that name will be disabled. Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete 70

these procedures. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To modify routing for a forest name suffix 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the forest root domain for the forest trust 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 routing for 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 routing for 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.

Modify Routing for a Subordinate Name Suffix
You can change the routing status (enable or disable) of a name suffix that is subordinate to the name of a forest. For example, if the wingtiptoys.com forest trusts the fabrikam.com forest and the fabrikam.com forest includes a child domain sales.fabrikam.com, you can enable or disable routing specifically for the child domain name suffix. You can use this procedure to modify routing of an existing subordinate name suffix by using Active Directory Domains and Trusts. You can also use 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 Overview (http://go.microsoft.com/fwlink/? LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

71

To modify routing for an existing subordinate name suffix 1. Open Active Directory Domains and Trusts. 2. In the console tree, right-click the forest root domain node for the forest trust 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 forest suffix whose subordinate name suffix you want to modify for routing, 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.

Exclude Name Suffixes from Routing to a Forest
You can use the following procedure to exclude existing name suffixes from routing to a forest by using the Active Directory Domains and Trusts snap-in. You can also use the Netdom commandline tool. For more information about how to use the Netdom command-line tool to modify name suffix routing settings, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Note When you exclude a name suffix, the Domain Name System (DNS) name and all child names of that name will be excluded. Membership in Domain Admins in the forest root domain or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To exclude name suffixes from routing to a forest 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) 72

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 whose subordinate name suffix you want 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.

Securing Domain and Forest Trusts
When you create a new trust in an existing forest in Active Directory Domain Services (AD DS), all communications over that trust are tightly secured. However, when you create a trust between your domain and another domain outside your forest, certain security issues are 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. This section includes the following tasks for securing domain and forest trusts: • • Configuring SID Filter Quarantining on External Trusts Configuring Selective Authentication Settings

For more information about how the security settings for domain and forest trusts work, see Security Considerations for Trusts (http://go.microsoft.com/fwlink/?LinkId=111846).

Configuring SID Filter Quarantining on External Trusts
Security principals in Active Directory Domain Services (AD DS) have an attribute, called SID history, to which domain administrators can add users’ old security identifiers (SIDs). This is useful during Active Directory migrations so that administrators do not have 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 attackers or rogue administrators that have compromised a domain controller in a trusted domain to use the SID history attribute (sIDHistory) to associate SIDs with new user accounts, granting themselves unauthorized rights. To help prevent this type of attack, SID filter quarantining is automatically enabled on all external trusts that are created from domain controllers running either Windows Server 2003 or Windows Server 2008. External trusts that are created from domain controllers running Windows 2000 Server with Service Pack 3 (SP3) or earlier do not have SID filter quarantining enforced by default. These external trusts must be configured manually to enable SID filter quarantining.

73

Note You cannot turn off the default behavior in Windows Server 2003 or Windows Server 2008 that enables SID filter quarantining for newly created external trusts. However, under certain conditions SID filter quarantining can be disabled on such an external trust. For information about conditions for disabling SID filter quarantining, see Disable SID filter Quarantining. External trusts that are created from domain controllers running Windows 2000 Server with SP3 or earlier do not enforce SID filter quarantining by default. To further secure your forest, consider enabling SID filter quarantining on all existing external trusts that are created from domain controllers running Windows 2000 Server SP3 or earlier. You can do this by using Netdom.exe to enable SID filter quarantining on existing external trusts or by recreating these external trusts from a domain controller running Windows Server 2008, Windows Server 2003, or Windows 2000 Server with Service Pack 4 (SP4). You can use SID filter quarantining to filter out migrated SIDs that are stored in SID history from specific domains. For example, where an external trust relationship exists so that the one domain, Contoso (running Windows 2000 Server domain controllers), trusts another domain, Cpandl (also running Windows 2000 Server domain controllers), an administrator of the Contoso domain can manually apply SID filter quarantining to the Cpandl domain, which allows all SIDs with a domain SID from the Cpandl domain to pass but all other SIDs (such as those from migrated SIDs that are stored in SID history) to be discarded. Note Do not apply SID filter quarantining to trusts within a forest that is not using either the Windows Server 2008 or Windows Server 2003 forest functional level, because doing so removes SIDs that are required for Active Directory replication. If the forest functional level is Windows Server 2008 or Windows Server 2003 and quarantining is applied between two domains within a forest, a user in the quarantined domain with universal group memberships in other domains in the forest might not be able to access resources in nonquarantined domains, because the group memberships from those domains are filtered when resources are accessed across the trust relationship. Likewise, SID filter quarantining should not be applied to forest trusts. For more information about how SID filtering works, see Security Considerations for Trusts (http://go.microsoft.com/fwlink/?LinkID=111846). 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 using the Netdom command-line tool to configure SID filtering settings, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). To complete this task, you can perform the following procedures: • • Disable SID filter Quarantining Reapply SID Filter Quarantining 74

Disable SID filter Quarantining
Although it is not recommended, you can use this procedure to disable security identifier (SID) filter quarantining for an external trust with the Netdom.exe tool. You should consider disabling SID filter quarantining 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 (the former domain of the migrated users) based on the sIDHistory attribute. For more information about how SID filtering works, see Security Considerations for Trusts (http://go.microsoft.com/fwlink/?LinkID=111846). You can disable SID filter quarantining by using the Netdom command-line tool. For more information about the Netdom command-line tool, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. To disable SID filter quarantining for the trusting domain 1. Open a Command Prompt. 2. At the command prompt, type the following command, and then press ENTER:
Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:No /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

75

Parameter

Description

<TrustingDomainName>

The Domain Name System (DNS) name (or 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 filter quarantining only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filter quarantining in the trusted domain by using the domain administrator’s credentials for the trusted domain and reversing the <TrustingDomainName> and <TrustedDomainName> values in the command-line syntax.

See Also
Reapply SID Filter Quarantining

Reapply SID Filter Quarantining
You can use this procedure to reapply security identifier (SID) filter quarantining to an external trust that has had SID filter quarantining disabled. Also, use this procedure to apply SID filter quarantining to any external trust that has been created from a Windows 2000 Server domain controller. By default, SID filter quarantining is enabled automatically on all external trusts that are created from a Windows Server 2003 or Windows Server 2008 domain controller. For more information about how SID filter quarantining works, see Security Considerations for Trusts (http://go.microsoft.com/fwlink/?LinkID=111846). You can reapply SID filter quarantining by using the Netdom command-line tool. For more information about the Netdom command-line tool, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the trusting domain or Enterprise Admins in the forest of the trusting domain Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 76

To reapply SID filter quarantining for the trusting domain 1. Open a Command Prompt. 2. At the command prompt, type the following command, and then press ENTER:
Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

Term

Definition

<TrustingDomainName>

The Domain Name System (DNS) name (or 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 2008 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 and Windows Server 2008 forests, in any combination. 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 organization’s forest to a limited set of users in another organization’s forest. For more information about how selective authentication settings work, see Security Considerations for Trusts (http://go.microsoft.com/fwlink/?LinkID=111846). Task requirements Either of the following tools is required to perform the procedures for this task: • Active Directory Domains and Trusts 77



Netdom.exe

For more information about how to use the Netdom command-line tool to configure selective authentication settings, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). To complete this task, you can 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 Domain Services (AD DS). 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 (http://go.microsoft.com/fwlink/?LinkID=111846). To provide access to computers in the trusting domain to only those users in the trusted domain who have the Allowed to Authenticate permission applied to the computer objects, you can use this procedure to enable selective authentication over an external trust with the New Trust Wizard in the Active Directory Domains and Trusts snap-in or with the Netdom command-line tool. For more information about how to use the Netdom command-line tool to configure selective authentication settings, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477.

Enabling selective authentication over an external trust
• • Using the Windows interface Using a command line

78

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 two-way, 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. To enable selective authentication over an external trust using a command line 1. Open a Command Prompt. 2. At the command prompt, type the following command, and then press ENTER:
Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /SelectiveAUTH:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

Parameter

Description

<TrustingDomainName>

The Domain Name System (DNS) name (or NetBIOS name) of the trusting domain in the trust that is being managed. The DNS name (or NetBIOS name) of the domain that is trusted in the trust that is being managed. The user account name with the appropriate administrator credentials to modify the trust. The password of the user account in <DomainAdministratorAcct>.

<TrustedDomainName>

<DomainAdministratorAcct>

<DomainAdminPwd>

79

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 Domain Services (AD DS). For more information about granting the Allowed to Authenticate permission, 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 (http://go.microsoft.com/fwlink/?LinkID=111846). To provide access to computers in the trusting forest to only those users in the trusted forest who have the Allowed to Authenticate permission applied to the computer objects, you can use this procedure to enable selective authentication over a forest trust with the New Trust Wizard in the Active Directory Domains and Trusts snap-in or with the Netdom command-line tool. For more information about how to use the Netdom command-line tool to configure selective authentication settings, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537). Membership in Domain Admins in the forest root domain or Enterprise Admins in AD DS, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Enabling selective authentication over a forest trust
• • Using the Windows interface Using a command line

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 two-way, forest trust, 80

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. To enable selective authentication over a forest trust using a command line 1. Open a Command Prompt. 2. At the command prompt, type the following command, and then press ENTER:
Netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /SelectiveAUTH:Yes /userD:<DomainAdministratorAcct> /passwordD:<DomainAdminPwd>

Parameter

Description

<TrustingDomainName>

The Domain Name System (DNS) name (or NetBIOS name) of the trusting forest root domain in the trust that is being managed. The DNS name (or NetBIOS name) of the forest root domain that is trusted in the trust that is being managed. The user account name with the appropriate administrator credentials to modify the trust. The password of the user account in <DomainAdministratorAcct>.

<TrustedDomainName>

<DomainAdministratorAcct>

<DomainAdminPwd>

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 (http://go.microsoft.com/fwlink/? LinkID=111846). You can use this procedure to enable domain-wide authentication over an external trust. Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about

81

using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. To enable domain-wide authentication over an external trust 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 appear 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 two-way, 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 (http://go.microsoft.com/fwlink/?LinkID=111846). You can use this procedure to enable forest-wide authentication over a forest trust. Membership in Domain Admins or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. To enable forest-wide authentication over a forest trust 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. 82

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 two-way, 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 2008 or Windows Server 2003 domain or forest to be able to access resources in a trusting Windows Server 2008 or 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 (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, Windows Server 2003, and Windows Server 2008. You can use this procedure and the Active Directory Users and Computers snap-in from the trusting domain to enable access to resources over an external trust or forest trust that is set to selective authentication . Membership in Account Operators, Domain Admins, or Enterprise Admins in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To grant the Allowed to Authenticate permission on computers in the trusting domain or forest 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 83

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
An administrator in one domain configures the Direction of Trust page in the New Trust Wizard 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 trust direction 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 the users that reside in both domains or forests. A two-way trust allows authentication requests that 84

are sent by users in a trusted domain or forest to be routed successfully to the trusting domain or forest. Both domains or forests in the trust relationship are reciprocally trusting and trusted. 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. Instead, “incoming” and “outgoing” are used to indicate the direction of the trust, as described in the next sections.

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.

85

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.

86

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 and Windows Server 2008, you 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. 87

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-ofbusiness applications. The Windows Time service (W32time) 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 requests and resource access requests. This guide provides information about administering the Windows Time service in Windows Server 2008. In this guide • • Introduction to Administering the Windows Time Service Managing the Windows Time Service

Introduction to Administering the Windows Time Service
The Windows Server 2008 Windows Time service (W32time) synchronizes the date and time for all computers running on a Windows Server 2008 network. The service integrates Network Time Protocol (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 running versions of Windows 2000 Server, Windows Server 2003, Windows XP, Windows Vista, or Windows Server 2008 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. A domain controller at the top of the hierarchy provides authoritative time to all other domain controllers, and domain clients use domain controllers as their time source. By default, the domain controller at the top of the hierarchy is the primary domain controller (PDC) operations master (also known as flexible single master operations or FSMO) in the forest root domain.

Windows time source selection
By default, Windows-based computers use the following sources for time synchronization: 88

• For computers that are joined to a domain, the first query is to a time source in the parent domain. Note Computers that are not joined to a domain and are running Windows Vista are configured to synchronize with the following external time sources by default: time.windows.com, time.nist.gov, time-nw.nist.gov, time-a.nist.gov, and time-b.nist.gov. Computers that are not joined to a domain and are running Windows XP or Windows XP Home Edition are configured to synchronize with time.windows.com by default. • If the time client is in a single-domain forest, the first query is to the PDC emulator in the domain. • All PDC emulator operations masters follow the hierarchy of domains in the selection of their inbound time partner. A PDC emulator can synchronize its time from the PDC emulator in the parent domain or from any domain controller in the parent domain. For more information about time source selection, see How Windows Time Service Works (http://go.microsoft.com/fwlink/?LinkID=117753). The authoritative time source at the root of the forest can acquire its time either by connecting to an installed hardware clock on the internal network or by connecting to an external NTP server, which is connected to a hardware device. If no domain controller is configured as the authoritative time source in the forest root domain, the domain controller that holds the PDC emulator operations master role uses its internal clock to provide time to forest computers.

External NTP time servers
Many external NTP servers are available over the Internet. Use the following information to select an NTP server: • The National Institute of Standards and Technology (NIST) in Boulder, Colorado, which is used as the external time provider by the Microsoft time server (time.windows.com). NIST provides the Automated Computer Time Service (ACTS), which can set a computer clock with an uncertainty of less than 10 milliseconds. For more information about NTP and for a list of external time servers, see Set Your Computer Clock Via the Internet: NIST Internet Time Service (ITS) (http://go.microsoft.com/fwlink/?LinkId=112035). • The U.S. Naval Observatory (USNO) Time Service Department in Washington, DC, is another reliable source for accurate time synchronization in the United States. To see a list of USNO servers and their descriptions, see USNO Network Time Servers (http://go.microsoft.com/fwlink/?LinkId=112036). • You can use many other sites throughout the world for time synchronization. For more NTP server lists and search criteria, see the NTP.Servers Web site (http://go.microsoft.com/fwlink/? LinkId=116972). For the most highly accurate time synchronization, configure a hardware clock, such as a radio or Global Positioning System (GPS) device, as the time source for the PDC. There are many 89

consumer and enterprise devices that use NTP, which makes it possible for you to install the device on an internal network for use with the PDC. You use the w32tm command-line tool to configure Windows Time service. For a detailed technical reference for the Windows Time service, including complete documentation of the w32tm command-line tool and time service registry settings, see the Windows Time Service Technical Reference (http://go.microsoft.com/fwlink/?LinkID=100940).

W32tm and net time
The net time commands are predecessors of w32tm commands, and they should not be used to configure the Windows Time service or to set the time on a computer while the Windows Time service is actively running. The recommended method for configuring the Windows Time service and displaying Windows Time service information for Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 operating systems is to use w32tm commands. Although the command net time /querysntp appears to display the Simple Network Time Protocol (SNTP) server for Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008 operating systems, it does not display complete time configuration information. You can use the command w32tm /query /configuration to determine whether the computer is configured to synchronize time from the domain hierarchy or from a manual list of time servers. The command output includes a line labeled Type that identifies the time synchronization method that the client is using. The following Type line outputs are possible for the time client: • NoSync: The client does not synchronize time. • NTP: The client synchronizes time from an external time source. Review the values in the NtpServer line in the output to see the name of the server or servers that the client uses for time synchronization. • NT5DS: The client is configured to use the domain hierarchy for its time synchronization. • AllSync: The client synchronizes time from any available time source, including domain hierarchy and external time sources. For information about Windows Time Server Internet communication, see Windows Time Service and Resulting Internet Communication in Windows Server 2008 (http://go.microsoft.com/fwlink/? LinkId=116982).

Managing the Windows Time Service
You initially configure the Windows Time service (W32time) when you deploy your forest root domain in Active Directory Domain Services (AD DS). Thereafter, the Windows Time service requires little day-to-day management. After you make changes on your network, however, including adding certain client computers, moving the primary domain controller (PDC) emulator operations master role, or simply changing the time source for your network, you might need to perform certain tasks. This section includes the following tasks for managing the Windows Time service: 90

• • •

Configuring a Time Source for the Forest Configuring Windows-Based Clients to Synchronize Time Restoring the Windows Time Service to Default Settings

Configuring a Time Source for the Forest
The first domain controller that you deploy in a domain holds the primary domain controller (PDC) emulator operations master (also known as flexible single master operations or FSMO) role for the domain. By default, the domain controller that holds the PDC emulator master role in the forest root domain is the reliable time source at the top of the time-source domain hierarchy for the forest. As soon as you install the first domain controller in the forest, set the PDC emulator in the forest root domain to synchronize from a valid Network Time Protocol (NTP) source or from a hardware clock that is installed on the network. If no time source is configured on the PDC emulator or any other domain controller in the forest root domain, the PDC emulator advertises as a reliable time source and uses its internal clock as the source for forest synchronization. In this case, no manual configuration is required. After initial deployment of your network, you typically reconfigure the time service on the PDC emulator in the forest root domain in only two situations: • You move the PDC emulator role to a different computer. In this case, you must configure the Windows Time service for the new PDC emulator master role holder and reconfigure the original PDC emulator master role holder to synchronize from the domain and not from an external or internal time source. • You change the time source for the PDC emulator. For example, you change from synchronizing with an external source to synchronizing with an internal hardware device. In some environments, one or more domain controllers are configured to act as standby PDC emulator role holders. If the current PDC emulator fails or is otherwise unavailable, the role can quickly be transferred to the standby. If you anticipate moving the PDC emulator role and you want to avoid reconfiguring the new and old PDC emulator every time the role is moved, you can configure a domain controller in the forest root domain that is not the PDC emulator as the reliable time source for the forest. In this way, the root of the time service stays the same and remains properly configured. Note Make sure that the domain controller that you configure to be the forest time source is highly available and, if it is not the PDC emulator, that it does not hold other operations master roles that might have to be transferred. Use the following recommendations for configuring the time source for the forest root domain, in this order of preference: 1. Install a hardware clock, such as a radio or Global Positioning System (GPS) device, as the time source for the forest root domain and configure Windows Time service (W32time) on the PDC emulator or other domain controller to synchronize with this device. Many consumer 91

and enterprise devices are available that use NTP. You can install the device on an internal network and configure the PDC emulator to use it as its time source. Hardware clocks have the following advantages: • More security. You do not have to connect to the Internet. • Highest accuracy, although the accuracy level of NTP servers is as high as that of Windows Time service; that is, the effect of the higher accuracy is not appreciated. Hardware clocks have the following disadvantage: • Expense and maintenance. You must purchase and install a hardware clock, whereas you can connect to a public time server at no cost and without hardware installation. 2. Configure the Windows Time service on the PDC emulator or other domain controller to synchronize with an external time server. Computer clocks synchronize with external time servers by using the NTP protocol over an IP version 4 (IPv4) or IP version 6 (IPv6) network. You can manually configure the PDC emulator in the forest root domain to synchronize with the external time source. External time servers have the following advantages: • Low cost or no cost. Cost is usually limited to bandwidth. • Good accuracy. Although hardware clocks have the highest accuracy, the accuracy of a hardware clock can actually exceed the accuracy of Windows Time service; therefore, the comparison of accuracy is not relevant. External time servers have the following disadvantage: • Security risk. NTP synchronization with an external time source is not authenticated and is therefore less secure than if the time source is inside the network. If you are using an external time source, you can use the following sites to select an NTP server: • USNO NTP Network Time Servers (http://go.microsoft.com/fwlink/?LinkId=112036) • Set Your Computer Clock Via the Internet: NIST Internet Time Service (ITS) (http://go.microsoft.com/fwlink/?LinkId=112035) • NTP.Servers Web site (http://go.microsoft.com/fwlink/?LinkID=116972) If you choose to implement an NTP time synchronization product other than the Windows Time service, you must disable the Windows Time service on the forest root domain reliable time source. All NTP servers need access to UDP port 123. If the Windows Time service is running on a Windows Server 2003–based computer or a Windows Server 2008–based computer, port 123 will remain occupied for the Windows Time service. Task requirements The following tools are required to perform the procedures for this task: • W32tm.exe • The Windows Firewall with Advanced Security snap-in, if you need to check User Datagram Protocol (UDP) port status • The Services snap-in, if you need to disable the Windows Time service To complete this task, perform the following procedures as needed: 92

• To configure the PDC emulator in the forest root domain to synchronize time from an external time source, see Configure the Time Source for the Forest. If you plan to use a different domain controller as the time source for the forest, perform this procedure on that domain controller instead of the PDC emulator. • If the PDC emulator in the forest root domain is configured as the reliable time source for the forest and you move the PDC emulator role to a different domain controller, see Change the Windows Time Service Configuration on the PDC Emulator in the Forest Root Domain. • If you are implementing a time synchronization product other than the Windows Time service in your environment that uses NTP, see Disable the Windows Time Service to free UDP port 123 on the network. • If you need more information about Windows Time service events, see Enable Windows Time Service Debug Logging.

Configure the Time Source for the Forest
You can use these procedures to configure the Windows Time service (W32time) on the domain controller that holds the primary domain controller (PDC) emulator operations master role in the forest root domain to synchronize time from an external time server or a reliable time source. 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, you must configure the PDC emulator role holder in the forest root domain to synchronize time for the forest from an external time source on the Internet or from a hardware clock on the internal network. If you do not configure the PDC emulator to synchronize time from an external or internal time source, the PDC emulator uses its internal clock and is itself the reliable time source for the forest. As an alternative to configuring the PDC emulator, you can configure a different domain controller in the forest root domain to synchronize time from a reliable time source. If there is such a domain controller in the forest root domain, the PDC emulator no longer advertises as a reliable time source. The procedures in this topic configure the PDC emulator (or other domain controller) to connect to an external Network Time Protocol (NTP) time server for time synchronization. To configure the PDC emulator to synchronize time from a hardware clock device on the internal network, consult the instructions for the hardware clock device. If you move the role of the PDC emulator to a new domain controller, you must also change the configuration of the Windows Time service on the previous PDC emulator. For more information, see Change the Windows Time Service Configuration on the PDC Emulator in the Forest Root Domain. Before you configure the Windows Time service on the PDC emulator, you can determine the time difference between it and the time source as a means to test basic NTP communication. If you have not selected a set of external NTP servers, use the following sites to create your list of time servers. This list is referred to in the procedure as the “manual peer list.” • USNO NTP Network Time Servers (http://go.microsoft.com/fwlink/?LinkId=112036). 93

• Set Your Computer Clock Via the Internet: NIST Internet Time Service (ITS) (http://go.microsoft.com/fwlink/?LinkId=112035). • NTP.Servers Web site (http://go.microsoft.com/fwlink/?LinkID=116972) After you configure the Windows Time service on the PDC emulator, be sure to monitor the System log in Event Viewer for W32time errors. Note The following procedures use the w32tm command-line tool. For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings (http://go.microsoft.com/fwlink/?LinkId=112116). Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure the time source for the forest 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. To display the time difference between the local computer and the target time source and to check NTP communication, at the command prompt, type the following command, and then press ENTER:
w32tm /stripchart /computer:<target> /samples:<n> /dataonly

Parameter

Description

W32tm /stripchart

Displays a strip chart of the offset between synchronizing computers. A strip chart plots two-dimensional data—in this case, the local time and the offset. Specifies the Domain Name System (DNS) name or IP address of the NTP server that you are comparing the local computer's time against, such as time.windows.com or time-nw.nist.gov. Specifies the number of time samples that will be returned from the target computer to test basic NTP communication. Specifies that results show only data, not graphics.

/computer:<target>

/samples:<n>

/dataonly

94

If this procedure fails, check the System event log for Time-Service errors and follow any resolution steps that are provided in the More Info link in the error. It is possible that a perimeter firewall is blocking access to the Internet time server. NTP port 123 must be open for outbound and inbound traffic on all routers and firewalls between the PDC emulator and the Internet. If necessary, enable debug logging for W32time, as described in Enable Windows Time Service Debug Logging. Resolve any NTP connection issues before you proceed to step 3. 3. To configure the PDC emulator to use an NTP time source, at the command prompt, type the following command, and then press ENTER:
w32tm /config /manualpeerlist:<peers> /syncfromflags:manual /reliable:yes /update

Parameter

Description

w32tm /config /update /manualpeerlist:<peers>

Configures the computer to synchronize time. Specifies the list of DNS names or IP addresses for the NTP time source with which the PDC emulator synchronizes. (This list is referred to as the manual peer list.) For example, you can specify time.windows.com as the NTP time server. When you specify multiple peers, use a space as the delimiter and enclose the names of the peers in quotation marks. Specifies that time will be synchronized with peers in the manual peer list. Specifies that the computer is a reliable time source.

/syncfromflags:manual /reliable:yes

Note When you specify a peer in the manual peer list, do not specify a computer that uses the forest root domain controller as its source for time, such as another domain controller in the forest. The time service does not operate correctly if there are cycles in the time source configuration. Peers should be external to the domain hierarchy. After you configure the PDC emulator as the time source for the forest, log on to a client computer in the forest root domain and perform steps 1 and 2 in the preceding procedure to check Windows Time service performance on the PDC emulator. Use the DNS name of the PDC emulator for the computer target in the command. If you receive error messages, the User Datagram Protocol (UDP) ports on the PDC emulator might be disabled or blocked. You can use the following procedure to check the port status on the PDC emulator, if necessary. 95

Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To check UDP port status on the PDC emulator 1. To check inbound UDP port 123 status on the domain controller that is the PDC emulator, click Start, point to Administrative Tools, and then click Windows Firewall with Advanced Security. 2. Click Inbound Rules. Check that Active Directory Domain Controller - W32Time (NTP-UDP-In) has a status of enabled (green) and is not blocked: • If this rule is disabled (dimmed), right-click the rule, and then click Enable. • If the rule is blocked, right-click the rule, and then click Properties. Under Action, click Allow the connections, and then click OK. 3. To check outbound UDP port status on the domain controller, click Outbound Rules. 4. Check that Active Directory Domain Controller (UDP-Out) has a status of enabled and is not blocked: • If the rule is disabled (dimmed), right-click the rule, and then click Enable. • If the rule is blocked, right-click the rule, and then click Properties. Under Action, click Allow the connections, and then click OK. Or To open only outbound UDP port 123, create a separate outbound rule for the specific port, as follows: a. In Windows Firewall with Advanced Security, right-click Outbound Rules, and then click New. b. In the New Outbound Rule Wizard, click Port, and then click Next. c. Click UDP, click Specific local ports, type 123, and then click Next. d. Follow the directions in the wizard to configure the security settings and name the rule, and then click Finish. 5. To ensure that the PDC emulator responds, on an NTP client, repeat the test in step 2 of the procedure “To configure the Windows Time service on the PDC emulator” earlier in this topic.

96

Change the Windows Time Service Configuration on the PDC Emulator in the Forest Root Domain
The domain controller in the forest root domain that holds the primary domain controller (PDC) emulator operations master (also known as flexible single master operations or FSMO) role is the default time source for the domain hierarchy of time sources in the forest. When you create the forest, you configure this domain controller either to connect to a manual time source (an external Network Time Protocol (NTP) server or a hardware clock device on the internal network) or to use its own internal clock as its time source. If you move the PDC emulator role to another domain controller or if you decide to configure a different domain controller as the reliable time source for the forest, you can use this procedure to change the Windows Time service (W32time) configuration on the PDC emulator that is currently configured as the reliable time source for the forest. Note The following procedure uses the w32tm command-line tool. For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings (http://go.microsoft.com/fwlink/?LinkId=112116). Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the Windows Time service configuration on the PDC emulator in the forest root domain 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
w32tm /config /syncfromflags:domhier /reliable:no /update

97

Parameter

Description

W32tm /config /update /syncfromflags:domhier

Configures the client to synchronize time. Specifies that time will be synchronized with the nearest time source in the domain hierarchy. Because this domain controller is in the forest root domain, it will synchronize with a reliable time source in the forest root domain. Removes the status of reliable time source.

/reliable:no

3. At the command prompt, type the following command, and then press ENTER:
net stop w32time

4. At the command prompt, type the following command, and then press ENTER:
net start w32time

Disable the Windows Time Service
You can use this procedure to disable the Windows Time service (W32time) if you choose to implement another time synchronization product that uses Network Time Protocol (NTP). Perform this procedure on the forest root domain reliable time source. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To disable the Windows Time service 1. Click Start, point to Administrative Tools, and then click Services. 2. Right-click Windows Time, and then click Properties. 3. In the Windows Time Properties dialog box, in Startup type, click Disabled, and then click OK. 4. In the Services list, verify that the Startup Type for the Windows Time service is Disabled.

98

Enable Windows Time Service Debug Logging
You can use this procedure to enable Windows Time service (W32time) debug logging when you need more information to solve a problem with Windows Time service configuration. Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To enable Windows Time Service debug logging 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. Create a folder to receive the Windows Time service log file. For example, in the command prompt window, type md c:\W32Time, and then press ENTER. This command creates a directory named W32Time on the C: drive. 3. To enable Windows Time service debug logging, at the command prompt, type the following command, and then press ENTER:
w32tm /debug /enable /file:c:\W32Time\w32time.log /size:10000000 /entries:0116

Configuring Windows-Based Clients to Synchronize Time
Certain Windows-based client computers do not automatically synchronize their time with their domain in Active Directory Domain Services (AD DS). The following client computers do not automatically synchronize to the domain time by using the Windows Time service (W32time): • • • 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

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

• • •

W32tm Configure a Manual Time Source for a Selected Client Computer Configure a Client Computer for Automatic Domain Time Synchronization

To complete this task, you can perform the following procedures:

Configure a Manual Time Source for a Selected Client Computer
You can use this procedure to configure a manual time source for a selected client computer. The default method of synchronizing time in a Windows forest is through the domain hierarchy, in which a client connects to a domain controller in its domain as its time source. A manual time source is a specified computer or computers from which the client synchronizes its time when it cannot synchronize through the domain hierarchy. To configure a computer for automatic domain time synchronization, see Configure a Client Computer for Automatic Domain Time Synchronization. Before you configure a manual time source for a client computer, you can determine the time difference between the time source and the computer as a means of testing basic Network Time Protocol (NTP) communication. After you complete the configuration of the manual time source on the client computer, be sure to monitor the System log in Event Viewer for Windows Time service (W32time) errors. Note The following procedure uses the w32tm command-line tool. For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings (http://go.microsoft.com/fwlink/?LinkId=112116). Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in the Domain Admins group, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure a manual time source for a selected client computer 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. To display the time difference between the local computer and a time source, at the command prompt, type the following command, and then press ENTER:
w32tm /stripchart /computer:<target> /samples:<n> /dataonly

100

Parameter

Description

W32tm /stripchart

Displays a strip chart of the offset between synchronizing computers. A strip chart plots two-dimensional data—in this case, the local time and the offset. Specifies the Domain Name System (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. Specifies that results show only data, not graphics.

/computer:<target>

/samples:<n>

/dataonly

3. Open UDP port 123 for outgoing traffic on the firewall, if necessary. 4. Open UDP port 123 (or a different port that you have selected) for incoming NTP traffic. 5. To configure a manual time source for the selected computer, at the command prompt, type the following command, and then press ENTER:
w32tm /config /manualpeerlist:<peers> /syncfromflags:manual /update

Parameter

Description

W32tm /config /update /manualpeerlist:<peers>

Configures the computer for time synchronization. Specifies the list of Domain Name System (DNS) names or IP addresses for the NTP time source with which the primary domain controller (PDC) emulator synchronizes. (This list is referred to as the manual peer list.) For example, you can specify time.windows.com as the NTP time server. When you specify multiple peers, use a space as the delimiter and enclose the names of the peers in quotation marks. Specifies that time is synchronized with peers in the manual peer list.

/syncfromflags:manual

101

Configure a Client Computer for Automatic Domain Time Synchronization
By default, a computer that is joined to a domain synchronizes time through the domain hierarchy of reliable time sources. However, if a computer has been manually configured to synchronize from a specific time source—perhaps because it was formerly not joined to the domain—you must reconfigure the computer to begin sourcing its time from the domain hierarchy. You can use this procedure to configure a client computer that is currently synchronizing with a manually specified computer to synchronize time automatically from the domain hierarchy. Note The following procedure uses the w32tm command-line tool. For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings (http://go.microsoft.com/fwlink/?LinkId=112116). Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in the Domain Admins group, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure a client computer for automatic domain time synchronization 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
w32tm /config /syncfromflags:domhier /update

Parameter

Description

W32tm /config /update /syncfromflags:domhier

Configures the computer for time synchronization. Specifies that time is synchronized with computers in the domain hierarchy.

3. At the command prompt, type the following command, and then press ENTER:
net stop w32time

4. At the command prompt, type the following command, and then press ENTER:
net start w32time

102

Restoring the Windows Time Service to Default Settings
If the local Windows Time service (W32time) settings are not configured correctly, 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 procedure for this task: • • W32tm.exe Restore the Windows Time Service on the Local Computer to the Default Settings To complete this task, perform the following procedure:

Restore the Windows Time Service on the Local Computer to the Default Settings
You can use this procedure to restore the Windows Time service (W32time) on the local computer to the default settings. If you are experiencing a problem, returning to the default settings might be more efficient than troubleshooting the problem. Note The following procedure uses the w32tm command-line tool. For more information about the w32tm command, type w32tm /? at a command prompt or see Windows Time Service Tools and Settings (http://go.microsoft.com/fwlink/?LinkId=112116). Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure locally. Membership in the Domain Admins group, or equivalent, is the minimum required to complete this procedure remotely. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To restore the Windows Time service on the local computer to the default settings 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop w32time

3. At the command prompt, type the following command, and then press ENTER:
w32tm /unregister

4. At the command prompt, type the following command, and then press ENTER: 103

w32tm /register

5. At the command prompt, type the following command, and then press ENTER:
net start w32time

Administering DFS-Replicated SYSVOL
This guide provides administering information for the SYSVOL shared folder in the Windows Server 2008. The information in this guide applies to newly installed Windows Server 2008 domains and domains that have been upgraded to the Windows Server 2008 domain functional level that are using Distributed File System (DFS) Replication for replication of the SYSVOL share. For information about managing SYSVOL in domains that are using File Replication Service (FRS), see Administering SYSVOL (http://go.microsoft.com/fwlink/?LinkId=112164). In this guide • • Introduction to Administering DFS-Replicated SYSVOL Managing DFS-Replicated SYSVOL

Introduction to Administering DFSReplicated SYSVOL
SYSVOL is a collection of folders that contain a copy of the domain’s public files, including system policies, logon scripts, and important elements of Group Policy objects (GPOs). The SYSVOL directory must be present and the appropriate subdirectories must be shared on a server before the server can advertise itself on the network as a domain controller. Shared subdirectories in the SYSVOL tree are replicated to every domain controller in the domain. Note For Group Policy, only the Group Policy template (GPT) is replicated through SYSVOL replication. The Group Policy container (GPC), which is stored in the domain, is replicated through Active Directory replication. For Group Policy to be effective, both parts must be available on a domain controller.

SYSVOL terminology and capitalization
SYSVOL is referred to as the “SYSVOL share.” The default root of the SYSVOL replica is at the path %systemroot%\SYSVOL\domain, but the folder that is actually shared by the domain controller is the %systemroot%\SYSVOL\sysvol folder by default.

104

Note The location of the SYSVOL directory and subdirectories is configurable during and after Active Directory installation. The default locations under %systemroot%\SYSVOL are used throughout this guide only as a relative reference to the location of SYSVOL files and folders. The %systemroot%\SYSVOL\domain and %systemroot%\SYSVOL\sysvol folders appear to contain the same content because SYSVOL uses junction points (also called reparse points). A junction point is a physical location on a hard disk that points to data that is located elsewhere on the hard disk or on another storage device. Junction points look like folders and behave like folders (in Windows Explorer they appear to be shortcuts to 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 open a command prompt and type dir to list the contents of \%systemroot%\SYSVOL\sysvol, you notice a folder that is listed as <JUNCTION>. The junction point in %systemroot%\SYSVOL\sysvol links to %systemroot %\SYSVOL\domain. In this guide, in reference to SYSVOL components and folders, the capitalization that is used reflects the capitalization of the default folders and parameters as they appear in the file system, in the registry, and in Active Directory Domain Services (AD DS). For example, the default SYSVOL directory tree always appears as %systemroot%\SYSVOL\sysvol, as it appears in Windows Explorer. When the topic is specific to the sysvol shared folder, lowercase sysvol is used. Similarly, the area of SYSVOL that is historically referred to as “the staging area” is described in this guide as “the staging areas subdirectory.” In this way, the folder “%systemroot%\SYSVOL\staging areas” is clearly understood and distinct from the “%systemroot%\SYSVOL\staging” folder. Capitalization of registry parameters and Active Directory attribute names are presented as they appear in those locations.

Using DFS Replication for replicating SYSVOL in Windows Server 2008
Distributed File System (DFS) Replication is a replication service that is available for replicating SYSVOL to all domain controllers in domains that have the Windows Server 2008 domain functional level. DFS Replication was introduced in Windows Server 2003 R2. However, on domain controllers that are running Windows Server 2003 R2, SYSVOL replication is performed by the File Replication Service (FRS). Note The information and instructions in this section relate to DFS Replication of SYSVOL. For information about managing SYSVOL when you use FRS for file replication, see Administering FRS-Replicated SYSVOL (http://go.microsoft.com/fwlink/?LinkId=122535). DFS Replication technology significantly improves replication of SYSVOL. In Windows 2000 Server, Windows Server 2003, and Windows Server 2003 R2, FRS is used to replicate the contents of the

105

SYSVOL share. When a change to a file occurs, FRS replicates the entire updated file. With DFS Replication, for files larger than 64 KB, only the updated portion of the file is replicated. To replicate only updates to files, DFS Replication uses an algorithm called remote differential compression (RDC). RDC detects changes to the data in a file and enables DFS Replication to replicate changes in the form of file blocks, without having to replicate the entire file. RDC detects insertions, removals, and rearrangements of data in files. The DFS Replication service monitors SYSVOL, and, if a change occurs to any file that is stored in SYSVOL, DFS Replication automatically replicates the file updates to the SYSVOL folders on the other domain controllers in the domain. An additional improvement is that DFS Replication does not require the version vector join (vvjoin) operation, which is performed between FRS replication partners when new connections are created. Vvjoin is a CPU-intensive operation that can affect the performance of the server and cause increased replication traffic. In Windows Server 2008, DFS Replication is the default file replication service for domains that are initially created on domain controllers running Windows Server 2008. However, in a domain that is upgraded from another operating system to Windows Server 2008, FRS is the default replication service for SYSVOL replication. To implement DFS Replication of SYSVOL after an upgrade to Windows Server 2008 domain functional level, you must perform a preliminary migration process for replication of the SYSVOL tree.

Requirements for using DFS Replication
In Windows Server 2008, for newly created domains operating at the Active Directory domain functional level of Windows Server 2008, DFS Replication is used by default for SYSVOL replication. If your domain controllers are upgraded from another operating system to Windows Server 2008, you must install DFS Replication on all domain controllers in the domain, raise the domain functional level to Windows Server 2008, and then follow a migration process to move from using FRS replication of SYSVOL to DFS Replication. For more information about the SYSVOL migration process, see SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process (http://go.microsoft.com/fwlink/?LinkID=119296). For more information about DFS Replication, see Distributed File System Replication: Frequently Asked Questions (http://go.microsoft.com/fwlink/?LinkId=122537). The day-to-day operation of SYSVOL replication is an automated process that does not require any human intervention other than watching for alerts that the DFS Replication service raises. Occasionally, you might perform some system maintenance as you change your network. The topics in this section describe the tasks that are required for managing SYSVOL replication, including maintaining capacity and relocating SYSVOL components.

Key considerations for administering SYSVOL
A new graphical user interface (GUI) management tool, DFS Management, provides options for performing many SYSVOL management tasks. In Windows Server 2003, most SYSVOL management tasks required registry changes. In Windows Server 2008, you can use DFS Management to perform the following SYSVOL updates: 106

• •

Change the space that is allocated to the staging area Change the staging area path Note You cannot use DFS Management to change the SYSVOL path. You must make this change in the registry directly. For information about changing the SYSVOL path, see Relocating SYSVOL Manually.



View shared folders

You can use the Diagnostic Reports features of DFS Management to implement a monitoring system to detect low disk space and other potential DFS Replication disruptions so that you can resolve these issues before the system stops replicating. The Ultrasound utility, which is a tool for monitoring FRS, cannot be used for DFS Replication. Instead, you can use the DFS Replication health reports that DFS Management generates. For information about using DFS Management to generate diagnostic reports, see Create a Diagnostic Report for DFS Replication (http://go.microsoft.com/fwlink/?LinkId=122538). Other key considerations for managing SYSVOL include the following: • Capacity To manage SYSVOL, enough space must be provided to store SYSVOL. The quota that is allocated to the DFS Replication staging area is 4 gigabytes (GB) (4096 MB). The maximum size is 4 terabytes (TB) (4096 GB). Depending on 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 installation of Active Directory Domain Services (AD DS) grows in size and complexity, the required capacity can exceed the available disk space. If you receive indications that disk space is low, determine whether the cause is attributable to inadequate physical space on the disk or the DFS Management setting that limits the quota that is allocated to the staging area. If staging area disk space is low, DFS Replication encounters frequent staging area cleanup events. You can avoid this scenario by using .admx file capability to implement a Central Store in SYSVOL to store and to replicate Windows Vista policy files. For information about using this solution, see article 929841 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=122539). You can also reduce SYSVOL size and replication time by managing Administrative Templates in Group Policy. For information about using this solution, see article 813338 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=122540). • Hardware maintenance System maintenance, such as removal of a disk drive, can make it necessary for you to relocate SYSVOL. Even if the maintenance occurs on a different disk drive, verify that the maintenance does not affect SYSVOL. Logical drive letters can change after you add and remove disks. DFS Replication locates SYSVOL by using paths that are stored in AD DS. If drive letters change after you add or remove disk drives, you must manually update the paths in AD DS. • Backing up GPOs 107

The successful operation of Group Policy depends on the reliable operation of SYSVOL. Key components of GPOs exist in SYSVOL (in the policies subdirectory), and it is essential that these GPO components remain synchronized with related components in AD DS. 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 UI-based 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. GPOs are included in system state backups. For information about backing up system state, see Backing Up Active Directory Domain Services. For information about backing up GPOs, see Back Up a Group Policy Object (http://go.microsoft.com/fwlink/?LinkID=122542). • Relocating SYSVOL When you relocate SYSVOL, you must first copy the entire folder structure to a new location. Then, you must update the junction points and path values that are stored in the registry and in AD DS to maintain the relationships between the paths, the folders, and the junctions. As an option, you can relocate the staging area and leave the rest of SYSVOL at its original location. In this case, you must update the staging folder path in AD DS.

Relocating SYSVOL folders
SYSVOL relocation should be undertaken only when required by disk space maintenance or upgrades. By default, SYSVOL is contained in the %systemroot%\SYSVOL folder. The tree of folders that is contained within this folder can be extensive, depending on the size of SYSVOL, number of GPOs, and use of logon scripts. When you relocate SYSVOL folders, ensure that you copy all folders (including any hidden folders) and ensure that the relationships of the folders do not change. Note To ensure that all folders appear in Windows Explorer, on the Tools menu, click Folder Options. On the View tab, select Show hidden files and folders. Before you attempt to relocate all or portions of SYSVOL, you must clearly understand the folder structure and the relationships between the folders and the path and size information that is stored in AD DS. When folders are moved, any associated values that are stored in AD DS and the registry must be updated to match the new location. The folder structure contains junction points that also require updating after folders are moved to a new location. When you relocate folders, you use the first three levels of subdirectories to properly update the path locations that DFS Replication uses. These levels are affected by junction points and parameter settings. These folders include the following: %systemroot%\SYSVOL %systemroot%\SYSVOL\domain %systemroot%\SYSVOL\domain\DfsrPrivate %systemroot%\SYSVOL\domain\Policies 108

%systemroot%\SYSVOL\domain\scripts %systemroot%\SYSVOL\staging %systemroot%\SYSVOL\staging\domain %systemroot%\SYSVOL\staging areas %systemroot%\SYSVOL\staging areas\<FQDN>, where FQDN is the fully qualified domain name of the domain that this domain controller hosts, for example, contoso.com. %systemroot%\SYSVOL\sysvol %systemroot%\SYSVOL\sysvol\<FQDN>, where FQDN is the fully qualified domain name of the domain that this domain controller hosts, for example, contoso.com. Note If any of the folders do not appear in Windows Explorer, click Tools, and then click Folder Options. On the View tab, click 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 notice that two special folders are listed as <JUNCTION>. Both folders labeled FQDN are junction points. The junction point in %systemroot %\SYSVOL\sysvol links to %systemroot%\SYSVOL\domain. The junction in %systemroot %\SYSVOL\staging areas links 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 SYSVOL tree, the registry and AD DS also store references to folders. These references contain paths that you must update if you change the location of the folder: • Registry: The SysVol Netlogon parameter in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. This registry entry stores the path to the sysvol shared folder (default %systemroot %\SYSVOL\sysvol). The Netlogon service uses this path to identify the location of the folder that it uses to create the SYSVOL and NETLOGON (scripts) share points. • AD DS: Two attributes in AD DS store the paths for the SYSVOL root and staging area folders, as shown in the following table.
Directory value Default referenced location Contents

msDFSR-RootPath msDFSR-StagingPath

%systemroot\SYSVOL\domain %systemroot\SYSVOL\staging\domain

Policies and scripts Staging area folders

Managing DFS-Replicated SYSVOL
This section includes the following tasks for managing DFS-Replicated SYSVOL: • Changing the Quota That Is Allocated to the SYSVOL Staging Area 109

• • • •

Relocating the SYSVOL Staging Area Relocating SYSVOL Manually Updating the SYSVOL Path Restoring and Rebuilding SYSVOL

Changing the Quota That Is Allocated to the SYSVOL Staging Area
The staging folder in SYSVOL, a subfolder of the staging areas folder, stores updates before they are replicated. It also stores updates that it has just received through replication before it updates the copy of the files in SYSVOL. DFS Replication compresses the data to save space in the staging folder and to reduce the time that is necessary to replicate the files. The default quota that is allocated to the staging folder is 4096 megabytes (MB), or 4 gigabytes (GB). The minimum quota is 10 MB and the maximum quota that can be allocated is 4096 GB, or 4 terabytes (TB). If you need more space in the staging folder and space is available on the volume, you can adjust the staging folder quota by using DFS Management. Task requirements The following tool is required to perform the procedures for this task: • • DFS Management Change the Quota That Is Allocated to the SYSVOL Staging Folder To complete this task, perform the following procedure:

Change the Quota That Is Allocated to the SYSVOL Staging Folder
You can use this procedure to modify the amount of disk space that is allocated to the staging folder in SYSVOL. If space is available on the volume, you can increase the quota that is allocated to the staging folder to improve SYSVOL replication efficiency. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the space that is allocated to the staging folder 1. On the Start menu, point to Administrative Tools, and then click DFS Management. 2. In the console tree, expand Replication, and then click Domain System Volume. 3. In the details pane, right-click the SYSVOL replication member whose staging folder allocation you want to change, and then click Properties. 110

4. On the Staging tab, change the value in Quota (in megabytes), and then click OK.

Relocating the SYSVOL Staging Area
When you install Active Directory Domain Services (AD DS), the Active Directory Domain Services Installation Wizard installs folders that are referred to as “the SYSVOL staging area.” The Active Directory Domain Services Installation Wizard creates two folders—%systemroot %\SYSVOL\staging and %systemroot%\SYSVOL\staging areas—which the Distributed File System (DFS) Replication service uses as the queue for changes that are to be replicated to other domain controllers. “Staging” and “staging areas” are default names. When you relocate these staging folders, you can change the name. Ensure that you identify the proper area in the SYSVOL tree in case it is renamed in your environment. Important Before you relocate all or part of SYSVOL, be sure to inform domain administrators that you are doing so and that they should not make any changes in the SYSVOL directory until the move is complete. Two values determine the location of the staging area: • The msDFSR-StagingPath attribute of the object CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DomainControllerName,OU=Domain Controllers,DC=DomainName in AD DS. This attribute contains the path to the actual location that DFS Replication uses to stage files. • A junction point that is stored in the staging areas folder in SYSVOL that links to the actual location that DFS Replication uses to stage files. After you move the staging areas folders, you must change the staging folder path in AD DS. The staging junction point is updated automatically to reference the new location when you restart the DFS Replication service and Netlogon service. You do not have to update the staging junction point manually. After you move the staging areas folders, force replication of the changes to a replication partner in the domain. Except where noted, perform these procedures on the domain controller that contains the staging folder that you want to relocate. Task requirements An understanding of the SYSVOL folder structure is necessary for this task. For information about the SYSVOL folder structure, see Introduction to Administering DFS-Replicated SYSVOL. The following tools are required to perform the procedures for this task: • • • • Active Directory Sites and Services Event Viewer Net.exe Dcdiag.exe 111

• • • • • • • • • • •

Regedit.exe ADSI Edit Identify Replication Partners Check the Status of the SYSVOL and Netlogon Shares Verify Active Directory Replication Gather the SYSVOL Path Information Stop the DFS Replication Service and Netlogon Service Create the SYSVOL Staging Areas Folder Structure Change the SYSVOL Root Path or Staging Areas Path, or Both Start the DFS Replication Service and Netlogon Service Force Replication Between Domain Controllers

To complete this task, perform the following procedures:

Identify Replication Partners
You can use this procedure to examine the connection objects for a domain controller and identify its replication partners. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To identify replication partners 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, double-click 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 then determine the site association. 4. Double-click the Servers folder to display the list of servers in that site. 5. Double-click the server object for the domain controller whose replication partners you want to identify to display its NTDS Settings object. 6. Click the NTDS Settings object to display the list of connection objects in the details pane. (These objects represent inbound connections that are used for replication to the server.) The From Server column displays the names of the domain controllers that are 112

source replication partners for the selected server object.

Check the Status of the SYSVOL and Netlogon Shares
You can use this procedure to make sure that the Distributed File System (DFS) Replication service is started properly and then ensure that the sysvol shared folder and netlogon (scripts) shared folder are created and shared. For information about checking SYSVOL status for File Replication Service (FRS), see the Windows Server 2003 topic Check the status of the shared SYSVOL (http://go.microsoft.com/fwlink/?LinkId=120774). Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To check the status of the SYSVOL and Netlogon shares 1. On the Start menu, point to Administrative Tools, and then click Services. 2. Verify that the DFS Replication service and the Netlogon service have a status of Started. If a service is stopped, click Restart. 3. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 4. To verify that the SYSVOL tree includes the sysvol and scripts shared folders, at the command prompt, type the following command, and then press ENTER:
net share

5. Check the list to be sure that it includes %systemroot%\SYSVOL\sysvol\ (the SYSVOL share) and %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS (the NETLOGON share), where <Domain Name> is the domain of the new domain controller. Note If neither %systemroot%\SYSVOL\sysvol\ nor %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS are present, see Verify Active Directory Replication. 6. Verify that the proper permissions are set for SYSVOL replication. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:netlogons

Look for a message that states that <ComputerName> passed test NetLogons, where <ComputerName> is the name of the domain controller. If you do not see the “passed test” 113

message, check the permissions that are set on the Scripts and Sysvol shared folders. For information about default SYSVOL permissions, see Reapply Default SYSVOL Security Settings.

Verify Active Directory Replication
You can use this procedure to verify that Active Directory replication is functioning properly on a domain controller. Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify Active Directory replication 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:replications

Note For more detailed replication information, use the /v option. If this test fails, open Event Viewer and check for errors in the Directory Service log. Use the information in the ActiveDirectory_DomainService replication events to troubleshoot the problem.

Gather the SYSVOL Path Information
When you relocate the SYSVOL tree or staging areas subtree, it is helpful to record the current and new values for the path locations in the SYSVOL tree that are required for SYSVOL to function. By recording these values in advance, you can facilitate the move process. When you move SYSVOL, you first copy the folder structure to a new location. Then, you update the locations where folder paths are specified: junction points in the file system, Netlogon parameters in the registry, and attributes in Active Directory Domain Services (AD DS). As an option, you can relocate the staging areas subtree and leave the rest of the SYSVOL tree at its original location. In this case, you must update an attribute in AD DS, but the junction point for the staging areas folder is updated automatically. You also have to record this path information when 114

you are rebuilding SYSVOL on one domain controller by importing the SYSVOL of another domain controller. Note The instructions in this procedure relate to domains in which Distributed File System (DFS) Replication is used to replicate SYSVOL. For information about relocating SYSVOL when you use File Replication Service (FRS), see Relocating SYSVOL Manually (http://go.microsoft.com/fwlink/?LinkId=122590). For more information about the folder structure and the relationships between the folders and the path information that is stored in the registry, AD DS, and the SYSVOL directory itself, see Introduction to Administering DFS-Replicated SYSVOL. You can use these procedures to locate the SYSVOL path information and then record the values in the following table. Use the rows and columns in the table according to the goals of your procedure. Record the current values and also the new values if you are moving the SYSVOL tree or the staging areas subtree or if you are rebuilding SYSVOL: • Relocating the entire SYSVOL tree: Record the current and new path values in rows 1 through 5. • Relocating the staging areas subtree only: Record the current and new path values in rows 2 and 5. • Restoring and rebuilding SYSVOL: Record path information as follows: • Record the current values from the domain controller that you are restoring in rows 1, 2, and 3. • In the Current Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller from which you are copying the SYSVOL folder structure. • In the New Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller whose SYSVOL you are rebuilding.
Parameter Current value New value

1 2 3 4 5

msDFSR-RootPath in AD DS msDFSR-StagingPath in AD DS SysVol Netlogon parameter in the registry Sysvol junction point Staging areas junction point

115

To gather the SYSVOL path information
Perform the following procedures to gather values for SYSVOL paths and record the data in the preceding table. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the msDFSR-RootPath and the msDFSR-StagingPath values in AD DS 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 2. Right-click ADSI Edit, and then, if the domain whose path information you want to check is not listed, click Connect to. 3. Under Connection Point, click Select a well known Naming Context, click Default naming context, and then click OK. 4. In the tree view, expand the domain component, and then expand OU=Domain Controllers. 5. Double-click the container that represents a domain controller on which you can check the path information, double-click CN=DFSR-LocalSettings, and then click CN=Domain System Volume. 6. In the details pane, right-click CN=SYSVOL Subscription, and then click Properties. 7. Click Filter. Ensure that Show mandatory attributes is selected. Select this option if it is not selected. 8. In Attributes, locate msDFSR-RootPath and msDFSR-StagingPath, and then record the current values in rows 1 and 2, respectively, in the previous table. If you are moving SYSVOL, also record the new values for the new location in both rows. If you are moving the staging areas subtree, record the new path value in row 2. 9. Click Cancel to close the CN=Subscription Properties dialog box. To determine the SysVol Netlogon parameter value 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\Parameters. 3. In the details pane, double-click SysVol. The current value is listed in Value data. 4. Record the current value in row 3 of the previous table, and then click Cancel to close the Edit String dialog box. If you are moving SYSVOL, also record the new value for the new location. 5. Close Registry Editor. To determine the value in the sysvol junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click 116

Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\sysvol, or to the current location if SYSVOL has been moved from the default location. 3. To view the junction point for the sysvol folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. Record the current value in row 4 in the previous table. If you are moving SYSVOL, also record the new value for the new location. To determine the value in the staging areas junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\staging areas or to the current location if the staging areas subtree has been moved from the default location. 3. To view the junction point for the staging areas folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. The output identifies the <JUNCTION> folder type and the value that is stored in the staging areas junction point in brackets. For example, the default value is [Drive:\ %systemroot%\SYSVOL\staging\domain] (or, if SYSVOL has been migrated from FRS to DFS Replication, [Drive:\%systemroot%\SYSVOL_DFSR\staging\domain]). Record the current value in row 5 of the previous table. If you are moving SYSVOL or the staging areas subtree, also record the new value for the new location.

Stop the DFS Replication Service and Netlogon Service
You can use this procedure to stop the Distributed File System (DFS) Replication service and the Netlogon service when you are performing offline updates to the SYSVOL tree. The Netlogon service advertises the server as a domain controller by sharing out the SYSVOL folder. The services must be turned off until updates to the SYSVOL path information are complete and the SYSVOL junction point has been updated for the new location.

117

You can use the Windows graphical user interface (GUI) or the command line to stop the DFS Replication service and the Netlogon service. Note The staging path junction point is updated automatically when DFS Replication is restarted. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To stop the DFS Replication service or Netlogon service, or both, by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click Services. 2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop. To stop the DFS Replication service and the Netlogon service by using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop dfsr

3. At the command prompt, type the following command, and then press ENTER:
net stop netlogon

After you move or restore SYSVOL, when you update the SYSVOL Netlogon path in the registry, you must also update the SysvolReady parameter in Netlogon parameters, as described in Change the SYSVOL Netlogon Parameters.

Create the SYSVOL Staging Areas Folder Structure
You can use this procedure to create the SYSVOL staging areas subdirectory folder structure when you move the staging areas tree to a new location. The %systemroot%\SYSVOL\staging areas folder is the top of the staging areas tree in SYSVOL. To move the staging areas tree properly, you must select and copy the contents of %systemroot%\SYSVOL\staging areas. A different subfolder of %systemroot%\SYSVOL is named staging. Ensure that you select the contents of the staging areas subfolder (%systemroot%\SYSVOL\staging areas) and not the staging subfolder (%systemroot%\SYSVOL\staging). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 118

To create the SYSVOL staging areas folder structure 1. In Windows Explorer, create a new folder for the new location of the staging areas folder. 2. Navigate to the folder that represents the top of your current staging areas tree. By default, this folder is %systemroot%\SYSVOL\staging areas. 3. In the console tree, right-click the staging areas folder, and then click Copy. 4. In the console tree, navigate to the new folder that you created for the staging areas tree, right-click the folder, and then click Paste. Note This folder must be empty when you paste the staging areas folders. 5. Verify that the folder structure was copied correctly. To compare the new folder structure to the original, open a command prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 6. Change directories to the new staging areas folder. To list the contents of the folder and subfolders, type the following command, and then press ENTER:
dir /s

Ensure that all folders exist. If any folders are missing at the new location (such as \scripts), re-create them.

Change the SYSVOL Root Path or Staging Areas Path, or Both
If you are moving the SYSVOL tree or the SYSVOL staging areas tree, or if you are updating these locations after hardware reconfiguration that has resulted in a drive letter change, you can use this procedure to change the SYSVOL root path, the staging areas path, or both in Active Directory Domain Services (AD DS). Before you perform this procedure, you must stop the Distributed File System (DFS) Replication service and the Netlogon service, as described in Stop the DFS Replication Service and Netlogon Service. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the SYSVOL root path or the staging areas path, or both 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 119

2. Right-click ADSI Edit, and then, if the domain whose path information you want to check is not listed, click Connect to. 3. Under Connection Point, click Select a well known Naming Context, click Default naming context, and then click OK. 4. In the console tree, expand the domain component, and then expand OU=Domain Controllers. 5. Double-click the container that represents a domain controller on which you can check the path information, double-click CN=DFSR-LocalSettings, and then click CN=Domain System Volume. 6. In the details pane, right-click CN=SYSVOL Subscription, and then click Properties. 7. Click Filter. Ensure that Show mandatory attributes is selected. Select this option if it is not selected. 8. In Attributes, double-click one or both of the following: • • msDFSR-RootPath to change the SYSVOL root path. msDFSR-StagingPath to change the SYSVOL staging areas path.

9. In Value, type the new folder path, and then click OK. 10. Click OK to close the CN=Subscription Properties dialog box.

See Also
Start the DFS Replication Service and Netlogon Service

Start the DFS Replication Service and Netlogon Service
After you relocate the SYSVOL tree or the SYSVOL staging area, or both, use this procedure to restart the Distributed File System (DFS) Replication service, the Netlogon service, or both. After you restart the service or services, review the event log to ensure that the services restarted successfully. You can use the Windows graphical user interface (GUI) or the command line to start the DFS Replication service and the Netlogon service. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To start the DFS Replication service or Netlogon service, or both, by using the Windows GUI 1. On the Start menu, point to Administrative Tools and then click Services. 2. In the Name column, right-click DFS Replication or Netlogon, and then click Restart. 120

To start the DFS Replication service or Netlogon service, or both, by using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. To start the DFS Replication service, at the command prompt, type the following command, and then press ENTER:
net start dfsr

3. To start the Netlogon service, at the command prompt, type the following command, and then press ENTER:
net start netlogon

Notes • You can use Event Viewer to verify that DFS Replication restarted correctly. In the DFS Replication log (in Applications and Services Logs), Event ID 1004 indicates that the service restarted. Look for Event IDs 1210, 1206, and 6102 to verify that the domain controller is running and ready for service. If you moved SYSVOL to a new location or relocated the staging areas folder, look for Event IDs 4604 and 6018, which indicate success. Event ID 7036 in the System event log reports that the Netlogon service is running. This event reports on all services that are stopped or started. • Also verify that the Netlogon service is sharing the sysvol (SYSVOL share) and scripts (NETLOGON share) folders. At a command prompt, type net share, and then press ENTER.

Force Replication Between Domain Controllers
You can use this procedure to force Active Directory replication to occur between two domain controllers on a one-time basis when you want changes to be replicated from the server that received the changes to a server in another site sooner than the site link schedule allows. As an alternative, you can synchronize replication with all replication partners. Membership in Enterprise Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To force replication over a connection 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then expand the site to which you want to force 121

replication from the updated server. 3. Expand the Servers container to display the list of servers that are currently configured for that site. 4. Expand the server objects and click their NTDS Settings objects to display their connection objects in the details pane. Find a server that has a connection object from the server on which you made the updates. 5. Click NTDS Settings below the server object. In the details pane, right-click the connection object whose From Server is the domain controller that has the updates that you want to replicate, and then click Replicate Now. 6. When the Replicate Now message box appears, review the information, and then click OK.

See Also
Synchronize Replication with All Partners

Relocating SYSVOL Manually
If you want to move all folders in the SYSVOL directory, you can relocate these folders manually. You must carefully copy all folders and retain the same level of security at the new location. Caution The recommended method for relocating SYSVOL is to remove Active Directory Domain Services (AD DS) and then reinstall AD DS with the new SYSVOL path. Because of the potential for error, we do not recommend relocating SYSVOL manually. If you choose to move SYSVOL manually, you first copy the entire folder structure to a new location; then, you update the SYSVOL junction point and the parameters that are stored in the registry and in AD DS. As an option, you can relocate the staging areas subdirectory only. For information about relocating the staging areas subdirectory, see Relocating the SYSVOL Staging Area. Important Before you relocate all or part of SYSVOL, be sure to inform domain administrators that you are doing so and that they should not make any changes in the SYSVOL directory until the move is complete. Relocating SYSVOL can alter security settings if you do not use a copy method that retains file ownership and access control list (ACL) settings. The copy method that is described in this procedure retains security settings. After you move the SYSVOL tree, verify that the security settings on the relocated SYSVOL folders match the settings on the original SYSVOL folder structure. As an alternative, you can reapply security settings on the moved SYSVOL. When you have completed SYSVOL relocation, force replication from the updated domain controller to a replication partner in the domain. 122

Task requirements The following tools are required to perform the procedures for this task: • • • • • • • • • • Active Directory Sites and Services Net.exe Dcdiag.exe Event Viewer ADSI Edit Regedit.exe Dir.exe Windows Explorer Robocopy.exe Mklink.exe

• If you choose to reapply security settings manually, the following additional tools are required: • • Notepad.exe Secedit.exe

To complete this task, perform the following procedures: 1. Identify Replication Partners 2. Check the Status of the SYSVOL and Netlogon Shares 3. Verify Active Directory Replication 4. Gather the SYSVOL Path Information 5. Stop the DFS Replication Service and Netlogon Service 6. Copy SYSVOL to a New Location 7. Create the SYSVOL Root Junction Point 8. Change the SYSVOL Root Path or Staging Areas Path, or Both 9. Change the SYSVOL Netlogon Parameters 10. Reapply Default SYSVOL Security Settings You can use this procedure if you want to reapply the default security settings to the SYSVOL directory. However, if you use the Robocopy command that is specified in Copy SYSVOL to a New Location, file ownership and access control list (ACL) settings are retained on the copied SYSVOL folders and files, and reapplying security settings is not required. 11. Start the DFS Replication Service and Netlogon Service 12. Check the Status of the SYSVOL and Netlogon Shares 13. Force Replication Between Domain Controllers

123

Identify Replication Partners
You can use this procedure to examine the connection objects for a domain controller and identify its replication partners. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To identify replication partners 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, double-click 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 then determine the site association. 4. Double-click the Servers folder to display the list of servers in that site. 5. Double-click the server object for the domain controller whose replication partners you want to identify to display its NTDS Settings object. 6. Click the NTDS Settings object to display the list of connection objects in the details pane. (These objects represent inbound connections that are used for replication to the server.) The From Server column displays the names of the domain controllers that are source replication partners for the selected server object.

Check the Status of the SYSVOL and Netlogon Shares
You can use this procedure to make sure that the Distributed File System (DFS) Replication service is started properly and then ensure that the sysvol shared folder and netlogon (scripts) shared folder are created and shared. For information about checking SYSVOL status for File Replication Service (FRS), see the Windows Server 2003 topic Check the status of the shared SYSVOL (http://go.microsoft.com/fwlink/?LinkId=120774).

124

Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To check the status of the SYSVOL and Netlogon shares 1. On the Start menu, point to Administrative Tools, and then click Services. 2. Verify that the DFS Replication service and the Netlogon service have a status of Started. If a service is stopped, click Restart. 3. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 4. To verify that the SYSVOL tree includes the sysvol and scripts shared folders, at the command prompt, type the following command, and then press ENTER:
net share

5. Check the list to be sure that it includes %systemroot%\SYSVOL\sysvol\ (the SYSVOL share) and %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS (the NETLOGON share), where <Domain Name> is the domain of the new domain controller. Note If neither %systemroot%\SYSVOL\sysvol\ nor %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS are present, see Verify Active Directory Replication. 6. Verify that the proper permissions are set for SYSVOL replication. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:netlogons

Look for a message that states that <ComputerName> passed test NetLogons, where <ComputerName> is the name of the domain controller. If you do not see the “passed test” message, check the permissions that are set on the Scripts and Sysvol shared folders. For information about default SYSVOL permissions, see Reapply Default SYSVOL Security Settings.

Verify Active Directory Replication
You can use this procedure to verify that Active Directory replication is functioning properly on a domain controller. Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

125

To verify Active Directory replication 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:replications

Note For more detailed replication information, use the /v option. If this test fails, open Event Viewer and check for errors in the Directory Service log. Use the information in the ActiveDirectory_DomainService replication events to troubleshoot the problem.

Gather the SYSVOL Path Information
When you relocate the SYSVOL tree or staging areas subtree, it is helpful to record the current and new values for the path locations in the SYSVOL tree that are required for SYSVOL to function. By recording these values in advance, you can facilitate the move process. When you move SYSVOL, you first copy the folder structure to a new location. Then, you update the locations where folder paths are specified: junction points in the file system, Netlogon parameters in the registry, and attributes in Active Directory Domain Services (AD DS). As an option, you can relocate the staging areas subtree and leave the rest of the SYSVOL tree at its original location. In this case, you must update an attribute in AD DS, but the junction point for the staging areas folder is updated automatically. You also have to record this path information when you are rebuilding SYSVOL on one domain controller by importing the SYSVOL of another domain controller. Note The instructions in this procedure relate to domains in which Distributed File System (DFS) Replication is used to replicate SYSVOL. For information about relocating SYSVOL when you use File Replication Service (FRS), see Relocating SYSVOL Manually (http://go.microsoft.com/fwlink/?LinkId=122590). For more information about the folder structure and the relationships between the folders and the path information that is stored in the registry, AD DS, and the SYSVOL directory itself, see Introduction to Administering DFS-Replicated SYSVOL. You can use these procedures to locate the SYSVOL path information and then record the values in the following table. Use the rows and columns in the table according to the goals of your procedure. Record the current values and also the new values if you are moving the SYSVOL tree or the staging areas subtree or if you are rebuilding SYSVOL: 126

• Relocating the entire SYSVOL tree: Record the current and new path values in rows 1 through 5. • Relocating the staging areas subtree only: Record the current and new path values in rows 2 and 5. • Restoring and rebuilding SYSVOL: Record path information as follows: • Record the current values from the domain controller that you are restoring in rows 1, 2, and 3. • In the Current Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller from which you are copying the SYSVOL folder structure. • In the New Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller whose SYSVOL you are rebuilding.
Parameter Current value New value

1 2 3 4 5

msDFSR-RootPath in AD DS msDFSR-StagingPath in AD DS SysVol Netlogon parameter in the registry Sysvol junction point Staging areas junction point

To gather the SYSVOL path information
Perform the following procedures to gather values for SYSVOL paths and record the data in the preceding table. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the msDFSR-RootPath and the msDFSR-StagingPath values in AD DS 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 2. Right-click ADSI Edit, and then, if the domain whose path information you want to check is not listed, click Connect to. 3. Under Connection Point, click Select a well known Naming Context, click Default naming context, and then click OK. 4. In the tree view, expand the domain component, and then expand OU=Domain 127

Controllers. 5. Double-click the container that represents a domain controller on which you can check the path information, double-click CN=DFSR-LocalSettings, and then click CN=Domain System Volume. 6. In the details pane, right-click CN=SYSVOL Subscription, and then click Properties. 7. Click Filter. Ensure that Show mandatory attributes is selected. Select this option if it is not selected. 8. In Attributes, locate msDFSR-RootPath and msDFSR-StagingPath, and then record the current values in rows 1 and 2, respectively, in the previous table. If you are moving SYSVOL, also record the new values for the new location in both rows. If you are moving the staging areas subtree, record the new path value in row 2. 9. Click Cancel to close the CN=Subscription Properties dialog box. To determine the SysVol Netlogon parameter value 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\Parameters. 3. In the details pane, double-click SysVol. The current value is listed in Value data. 4. Record the current value in row 3 of the previous table, and then click Cancel to close the Edit String dialog box. If you are moving SYSVOL, also record the new value for the new location. 5. Close Registry Editor. To determine the value in the sysvol junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\sysvol, or to the current location if SYSVOL has been moved from the default location. 3. To view the junction point for the sysvol folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. Record the current value in row 4 in the previous table. If you are moving SYSVOL, also record the new value for the new location. To determine the value in the staging areas junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click 128

Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\staging areas or to the current location if the staging areas subtree has been moved from the default location. 3. To view the junction point for the staging areas folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. The output identifies the <JUNCTION> folder type and the value that is stored in the staging areas junction point in brackets. For example, the default value is [Drive:\ %systemroot%\SYSVOL\staging\domain] (or, if SYSVOL has been migrated from FRS to DFS Replication, [Drive:\%systemroot%\SYSVOL_DFSR\staging\domain]). Record the current value in row 5 of the previous table. If you are moving SYSVOL or the staging areas subtree, also record the new value for the new location.

Stop the DFS Replication Service and Netlogon Service
You can use this procedure to stop the Distributed File System (DFS) Replication service and the Netlogon service when you are performing offline updates to the SYSVOL tree. The Netlogon service advertises the server as a domain controller by sharing out the SYSVOL folder. The services must be turned off until updates to the SYSVOL path information are complete and the SYSVOL junction point has been updated for the new location. You can use the Windows graphical user interface (GUI) or the command line to stop the DFS Replication service and the Netlogon service. Note The staging path junction point is updated automatically when DFS Replication is restarted. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To stop the DFS Replication service or Netlogon service, or both, by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click Services. 2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop. To stop the DFS Replication service and the Netlogon service by using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control 129

dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop dfsr

3. At the command prompt, type the following command, and then press ENTER:
net stop netlogon

After you move or restore SYSVOL, when you update the SYSVOL Netlogon path in the registry, you must also update the SysvolReady parameter in Netlogon parameters, as described in Change the SYSVOL Netlogon Parameters.

Copy SYSVOL to a New Location
If you want to relocate the SYSVOL directory, you can use this procedure to create the new directory location and copy the SYSVOL folders to the new location. By default, the root of the SYSVOL directory is located at %systemroot%\SYSVOL. To move SYSVOL properly, you must correctly copy the contents of the SYSVOL folder. A subfolder with the default location of %systemroot%\SYSVOL is also named sysvol. Ensure that you copy the root folder (%systemroot %\SYSVOL) and not the subfolder (%systemroot%\SYSVOL\sysvol). Important To retain the SYSVOL security settings, you must use the proper robocopy command, as described in this procedure. If you perform a simple copy and paste in Windows Explorer, security settings are not copied. In this case, you must reapply security settings. For information about reapplying security settings, see Reapply Default SYSVOL Security Settings. For information about using robocopy, see Robocopy (http://go.microsoft.com/fwlink/?LinkId=122544). Before you perform this procedure, you must have performed the following procedures: • Identify Replication Partners. After you relocate SYSVOL, you will force replication of the changes to replication partners so that SYSVOL is updated as soon as possible on other domain controllers. • Check the Status of the SYSVOL and Netlogon Shares. Make sure that the sysvol and scrips folders are shared on the domain controller. • Verify Active Directory Replication. Make sure that you resolve any replication issues before you move SYSVOL. • Gather the SYSVOL Path Information. You must have the current path information, and you must also document the new location. • Stop the DFS Replication Service and Netlogon Service. Do not make any changes to the SYSVOL location while these services are running.

130

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To copy SYSVOL to a new location 1. In Windows Explorer, create a new folder for the new location of SYSVOL. This folder must be empty. 2. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 3. Change directories to the existing SYSVOL directory that you want to move. By default, the path to this directory is %systemroot%\SYSVOL. 4. At the command prompt, type the following command, and then press ENTER:
robocopy <Source Folder> <Destination Folder> /copyall /mir /b /r:0 /xd "DfsrPrivate" /xf "DfsrPrivate"

Note The destination folder must be empty.

131

Parameter

Description

<Source Folder>

The path to the SYSVOL directory that you are copying. The default location is %systemroot%\SYSVOL. The path to the new SYSVOL location that you created in step 1. Copies the following file information: data, attributes, time stamps, NTFS access control list (ACL), owner information, and auditing information. Mirrors the directory tree that you are copying. Copies files in backup mode. Robocopy uses backup mode to override file and folder permission settings (ACLs). Specifies performing 0 (zero) retries on failed copies. Excludes the DfsrPrivate directory from the copy. Excludes the DfsrPrivate file from the copy.

<Destination Folder> /copyall

/mir /b

/r:0 /xd "DfsrPrivate" /xf "DfsrPrivate"

5. Verify that the folder structure was copied correctly. To compare the new folder structure to the original, open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 6. Verify that the folder structure was copied correctly. To compare the new folder structure to the original, change directories to the new SYSVOL folder. To list the contents of the folder and subfolders by size, type the following command, and then press ENTER:
dir /s

Compare the ouptut with the output for the original SYSVOL folder. Ensure that all folders exist and that file sizes are the same. If any folders are missing at the new location (such as \scripts), re-create them. 7. Verify that the security settings on the moved SYSVOL are the same as the settings on the original location.

132

Create the SYSVOL Root Junction Point
If you move the SYSVOL tree, you must create a junction point that is named for the fully qualified domain name (FQDN) of the domain. You create this junction point under <NewLocationForSYSVOL>\sysvol. The junction point must point to <NewLocationForSYSVOL>\domain. If you move the tree or if hardware reconfiguration results in a change in the drive letter, you must recreate the SYSVOL junction point for the new location. To perform this procedure, you can use the Mklink.exe command-line tool, which is included with Windows Server 2008. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create the sysvol root junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, change the directory to the new sysvol root location, for example, FolderName\SYSVOL\sysvol. 3. To create the junction point for the sysvol root, at the command prompt, type the following command, and then press ENTER:
mklink /J <FQDN> <New sysvol root junction path>

Example: mklink
Parameter

/J contoso.com D:\ContosoRoot\SYSVOL\domain

Definition

mklink /J <FQDN> <New sysvol root junction path>

Creates a junction point for the specified domain in the specified path location. The fully qualified domain name of the SYSVOL domain The drive letter and path to the SYSVOL root, for example, Drive:\FolderName\SYSVOL\domain or Drive:\FolderName\SYSVOL_DFSR\domain if SYSVOL has been migrated from File Replication Service (FRS) to Distributed File System (DFS) Replication

4. To verify the creation of the junction point, at the command prompt, type the following command, and then press ENTER: 133

dir /a:L

Verify the presence of the <JUNCTION> folder type and the value that you specified in step 3.

Change the SYSVOL Root Path or Staging Areas Path, or Both
If you are moving the SYSVOL tree or the SYSVOL staging areas tree, or if you are updating these locations after hardware reconfiguration that has resulted in a drive letter change, you can use this procedure to change the SYSVOL root path, the staging areas path, or both in Active Directory Domain Services (AD DS). Before you perform this procedure, you must stop the Distributed File System (DFS) Replication service and the Netlogon service, as described in Stop the DFS Replication Service and Netlogon Service. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the SYSVOL root path or the staging areas path, or both 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 2. Right-click ADSI Edit, and then, if the domain whose path information you want to check is not listed, click Connect to. 3. Under Connection Point, click Select a well known Naming Context, click Default naming context, and then click OK. 4. In the console tree, expand the domain component, and then expand OU=Domain Controllers. 5. Double-click the container that represents a domain controller on which you can check the path information, double-click CN=DFSR-LocalSettings, and then click CN=Domain System Volume. 6. In the details pane, right-click CN=SYSVOL Subscription, and then click Properties. 7. Click Filter. Ensure that Show mandatory attributes is selected. Select this option if it is not selected. 8. In Attributes, double-click one or both of the following: • • msDFSR-RootPath to change the SYSVOL root path. msDFSR-StagingPath to change the SYSVOL staging areas path.

9. In Value, type the new folder path, and then click OK. 10. Click OK to close the CN=Subscription Properties dialog box. 134

See Also
Start the DFS Replication Service and Netlogon Service

Change the SYSVOL Netlogon Parameters
When you are relocating the SYSVOL tree, you can use this procedure to update the registry parameter that the Netlogon service uses to discover the path to the SYSVOL\sysvol shared folder. Netlogon advertises the shared folder location based on this registry entry. The default value in this entry is Drive:\%systemroot%\SYSVOL\sysvol. If you move the SYSVOL tree to a different folder or drive, or both, or if only the drive letter changes as a result of hardware updates, you must update this Netlogon parameter. When you update the SysVol Netlogon parameter in the registry, you must also change the SysvolReady Netlogon parameter so that SYSVOL is not advertised until all new path values have been initialized. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the SYSVOL Netlogon parameters 1. Click Start, click Run, type regedit, and then press ENTER. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. 3. Right-click SysVol, and then click Modify. 4. In the Value data box, type the new path, including the drive letter, and then click OK. 5. Right-click SysvolReady, and then click Modify. 6. In the Value data box, type 0, and then click OK. 7. Close Registry Editor. Note The path in the SysVol registry entry points to the sysvol shared folder, which is located inside the parent SYSVOL folder that is under the root (by default, Drive:\ %systemroot%\SYSVOL\sysvol). When you update the path, ensure that it still identifies the sysvol shared folder within the parent SYSVOL folder. If you have moved the SYSVOL tree, the root folder will change. Be sure to also change the drive letter to its new value if this has changed.

135

Reapply Default SYSVOL Security Settings
When you relocate the entire SYSVOL directory, you can use a robocopy command that transfers all security settings with the files when you copy them. Therefore, when you use the procedure in Administering the Windows Time Service to relocate SYSVOL, updating security settings is not required. However, if security settings are in question, you can use this procedure to reapply the default security settings to SYSVOL folders. The settings will be the equivalent of the settings that are set by default during installation of Active Directory Domain Services (AD DS). If additional security settings have been applied to SYSVOL folders since AD DS was installed, you must reapply those settings manually after you complete this procedure. Caution Failure to reapply security changes that were made after AD DS was installed might result in unauthorized access to logon and logoff scripts and Group Policy objects (GPOs). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To reapply default SYSVOL security settings 1. Click Start, click Run, type regedit, and then press ENTER. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Netlogon\Parameters. Double-click SysVol, and note the path in Value data. 3. In Control Panel, double-click System. 4. Under Tasks, click Advanced System Settings. 5. On the Advanced tab, click Environment Variables. 6. Under System Variables, click New. 7. For Variable name, type sysvol. 8. For Variable value, type the path that you noted in step 2. 9. Click OK twice. Click OK again to close System Properties. 10. Open Notepad, and then enter the following information: [Unicode] Unicode=yes [Version] signature="$CHICAGO$" Revision=1 [Profile Description] Description=default perms for sysvol 136

[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. Note Do not include a space between the sets of parentheses. 11. Save this file as Sysvol.inf. 12. 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 in step 11. 13. At the new command prompt, type the following command all on one line, and then press ENTER:
secedit /configure /cfg <path>\sysvol.inf /db <path>\sysvol.db /overwrite

Parameter

Description

/configure /cfg <path> (to security template) /db <path> (to database) /overwrite

Performs directed configurations. Specifies the path where you saved Sysvol.inf in step 11. Specifies the path to the database that is used to perform the security configuration. Specifies that the database should be emptied before it is imported into the security template. If this parameter is not specified, the settings in the security template are accumulated into the database. If this parameter is not specified and there are conflicting settings in the database and the template that is being imported, the template settings take precedence.

137

Start the DFS Replication Service and Netlogon Service
After you relocate the SYSVOL tree or the SYSVOL staging area, or both, use this procedure to restart the Distributed File System (DFS) Replication service, the Netlogon service, or both. After you restart the service or services, review the event log to ensure that the services restarted successfully. You can use the Windows graphical user interface (GUI) or the command line to start the DFS Replication service and the Netlogon service. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To start the DFS Replication service or Netlogon service, or both, by using the Windows GUI 1. On the Start menu, point to Administrative Tools and then click Services. 2. In the Name column, right-click DFS Replication or Netlogon, and then click Restart. To start the DFS Replication service or Netlogon service, or both, by using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. To start the DFS Replication service, at the command prompt, type the following command, and then press ENTER:
net start dfsr

3. To start the Netlogon service, at the command prompt, type the following command, and then press ENTER:
net start netlogon

Notes • You can use Event Viewer to verify that DFS Replication restarted correctly. In the DFS Replication log (in Applications and Services Logs), Event ID 1004 indicates that the service restarted. Look for Event IDs 1210, 1206, and 6102 to verify that the domain controller is running and ready for service. If you moved SYSVOL to a new location or relocated the staging areas folder, look for Event IDs 4604 and 6018, which indicate success. Event ID 7036 in the System event log reports that the Netlogon service is running. This event reports on all services that are stopped or started.

138

• Also verify that the Netlogon service is sharing the sysvol (SYSVOL share) and scripts (NETLOGON share) folders. At a command prompt, type net share, and then press ENTER.

Force Replication Between Domain Controllers
You can use this procedure to force Active Directory replication to occur between two domain controllers on a one-time basis when you want changes to be replicated from the server that received the changes to a server in another site sooner than the site link schedule allows. As an alternative, you can synchronize replication with all replication partners. Membership in Enterprise Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To force replication over a connection 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then expand the site to which you want to force replication from the updated server. 3. Expand the Servers container to display the list of servers that are currently configured for that site. 4. Expand the server objects and click their NTDS Settings objects to display their connection objects in the details pane. Find a server that has a connection object from the server on which you made the updates. 5. Click NTDS Settings below the server object. In the details pane, right-click the connection object whose From Server is the domain controller that has the updates that you want to replicate, and then click Replicate Now. 6. When the Replicate Now message box appears, review the information, and then click OK.

See Also
Synchronize Replication with All Partners

Updating the SYSVOL Path
When you add or remove disk drives, the logical drive letters of the other drives on the system can change. If either your %systemroot%\SYSVOL\sysvol folder or your %systemroot 139

%\SYSVOL\staging areas folder is located on one of the drives whose letter changes, Distributed File System (DFS) Replication cannot locate these folders. To solve this problem, you must update the paths that DFS Replication uses to locate these folders. Before you update SYSVOL path information, you must stop the DFS Replication service and the Netlogon service. To change the path for the %systemroot%\SYSVOL\sysvol root folder and staging areas folder, you update path values in Active Directory Domain Services (AD DS). You also update the registry to change the path to the %systemroot%\SYSVOL\sysvol shared folder that is used by the Netlogon service. In addition, you must update the junction point that references the %systemroot%\SYSVOL\domain folder in the SYSVOL tree. The junction point that references the domain folder in the staging areas subdirectory (%systemroot%\SYSVOL\staging areas\DomainName) is updated automatically when you restart DFS Replication and Netlogon. After you update the path information, when you restart DFS Replication and Netlogon, the new path values are initialized. To be sure that SYSVOL is not advertised on the network before the new paths are initalized, you must also modify the SysvolReady Netlogon parameter while the services are stopped. You can make this change at the same time you update the Sysvol Netlogon path in the registry. Task requirements The following tools are required to perform the procedures for this task: • • • • • Net.exe ADSI Edit Regedit.exe Dir.exe Mklink.exe

To complete this task, perform the following procedures in order: 1. Gather the SYSVOL Path Information 2. Stop the DFS Replication Service and Netlogon Service 3. Change the SYSVOL Netlogon Parameters 4. Create the SYSVOL Root Junction Point 5. Start the DFS Replication Service and Netlogon Service

Gather the SYSVOL Path Information
When you relocate the SYSVOL tree or staging areas subtree, it is helpful to record the current and new values for the path locations in the SYSVOL tree that are required for SYSVOL to function. By recording these values in advance, you can facilitate the move process. When you move SYSVOL, you first copy the folder structure to a new location. Then, you update the locations where folder paths are specified: junction points in the file system, Netlogon parameters in the registry, and attributes in Active Directory Domain Services (AD DS). As an option, you can relocate the staging areas subtree and leave the rest of the SYSVOL tree at its 140

original location. In this case, you must update an attribute in AD DS, but the junction point for the staging areas folder is updated automatically. You also have to record this path information when you are rebuilding SYSVOL on one domain controller by importing the SYSVOL of another domain controller. Note The instructions in this procedure relate to domains in which Distributed File System (DFS) Replication is used to replicate SYSVOL. For information about relocating SYSVOL when you use File Replication Service (FRS), see Relocating SYSVOL Manually (http://go.microsoft.com/fwlink/?LinkId=122590). For more information about the folder structure and the relationships between the folders and the path information that is stored in the registry, AD DS, and the SYSVOL directory itself, see Introduction to Administering DFS-Replicated SYSVOL. You can use these procedures to locate the SYSVOL path information and then record the values in the following table. Use the rows and columns in the table according to the goals of your procedure. Record the current values and also the new values if you are moving the SYSVOL tree or the staging areas subtree or if you are rebuilding SYSVOL: • Relocating the entire SYSVOL tree: Record the current and new path values in rows 1 through 5. • Relocating the staging areas subtree only: Record the current and new path values in rows 2 and 5. • Restoring and rebuilding SYSVOL: Record path information as follows: • Record the current values from the domain controller that you are restoring in rows 1, 2, and 3. • In the Current Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller from which you are copying the SYSVOL folder structure. • In the New Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller whose SYSVOL you are rebuilding.
Parameter Current value New value

1 2 3 4 5

msDFSR-RootPath in AD DS msDFSR-StagingPath in AD DS SysVol Netlogon parameter in the registry Sysvol junction point Staging areas junction point 141

To gather the SYSVOL path information
Perform the following procedures to gather values for SYSVOL paths and record the data in the preceding table. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the msDFSR-RootPath and the msDFSR-StagingPath values in AD DS 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 2. Right-click ADSI Edit, and then, if the domain whose path information you want to check is not listed, click Connect to. 3. Under Connection Point, click Select a well known Naming Context, click Default naming context, and then click OK. 4. In the tree view, expand the domain component, and then expand OU=Domain Controllers. 5. Double-click the container that represents a domain controller on which you can check the path information, double-click CN=DFSR-LocalSettings, and then click CN=Domain System Volume. 6. In the details pane, right-click CN=SYSVOL Subscription, and then click Properties. 7. Click Filter. Ensure that Show mandatory attributes is selected. Select this option if it is not selected. 8. In Attributes, locate msDFSR-RootPath and msDFSR-StagingPath, and then record the current values in rows 1 and 2, respectively, in the previous table. If you are moving SYSVOL, also record the new values for the new location in both rows. If you are moving the staging areas subtree, record the new path value in row 2. 9. Click Cancel to close the CN=Subscription Properties dialog box. To determine the SysVol Netlogon parameter value 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\Parameters. 3. In the details pane, double-click SysVol. The current value is listed in Value data. 4. Record the current value in row 3 of the previous table, and then click Cancel to close the Edit String dialog box. If you are moving SYSVOL, also record the new value for the new location. 5. Close Registry Editor.

142

To determine the value in the sysvol junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\sysvol, or to the current location if SYSVOL has been moved from the default location. 3. To view the junction point for the sysvol folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. Record the current value in row 4 in the previous table. If you are moving SYSVOL, also record the new value for the new location. To determine the value in the staging areas junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\staging areas or to the current location if the staging areas subtree has been moved from the default location. 3. To view the junction point for the staging areas folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. The output identifies the <JUNCTION> folder type and the value that is stored in the staging areas junction point in brackets. For example, the default value is [Drive:\ %systemroot%\SYSVOL\staging\domain] (or, if SYSVOL has been migrated from FRS to DFS Replication, [Drive:\%systemroot%\SYSVOL_DFSR\staging\domain]). Record the current value in row 5 of the previous table. If you are moving SYSVOL or the staging areas subtree, also record the new value for the new location.

Stop the DFS Replication Service and Netlogon Service
You can use this procedure to stop the Distributed File System (DFS) Replication service and the Netlogon service when you are performing offline updates to the SYSVOL tree. The Netlogon service advertises the server as a domain controller by sharing out the SYSVOL folder. The

143

services must be turned off until updates to the SYSVOL path information are complete and the SYSVOL junction point has been updated for the new location. You can use the Windows graphical user interface (GUI) or the command line to stop the DFS Replication service and the Netlogon service. Note The staging path junction point is updated automatically when DFS Replication is restarted. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To stop the DFS Replication service or Netlogon service, or both, by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click Services. 2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop. To stop the DFS Replication service and the Netlogon service by using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop dfsr

3. At the command prompt, type the following command, and then press ENTER:
net stop netlogon

After you move or restore SYSVOL, when you update the SYSVOL Netlogon path in the registry, you must also update the SysvolReady parameter in Netlogon parameters, as described in Change the SYSVOL Netlogon Parameters.

Change the SYSVOL Netlogon Parameters
When you are relocating the SYSVOL tree, you can use this procedure to update the registry parameter that the Netlogon service uses to discover the path to the SYSVOL\sysvol shared folder. Netlogon advertises the shared folder location based on this registry entry. The default value in this entry is Drive:\%systemroot%\SYSVOL\sysvol. If you move the SYSVOL tree to a different folder or drive, or both, or if only the drive letter changes as a result of hardware updates, you must update this Netlogon parameter. When you update the SysVol Netlogon parameter in the registry, you must also change the SysvolReady Netlogon parameter so that SYSVOL is not advertised until all new path values have been initialized. 144

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the SYSVOL Netlogon parameters 1. Click Start, click Run, type regedit, and then press ENTER. 2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. 3. Right-click SysVol, and then click Modify. 4. In the Value data box, type the new path, including the drive letter, and then click OK. 5. Right-click SysvolReady, and then click Modify. 6. In the Value data box, type 0, and then click OK. 7. Close Registry Editor. Note The path in the SysVol registry entry points to the sysvol shared folder, which is located inside the parent SYSVOL folder that is under the root (by default, Drive:\ %systemroot%\SYSVOL\sysvol). When you update the path, ensure that it still identifies the sysvol shared folder within the parent SYSVOL folder. If you have moved the SYSVOL tree, the root folder will change. Be sure to also change the drive letter to its new value if this has changed.

Create the SYSVOL Root Junction Point
If you move the SYSVOL tree, you must create a junction point that is named for the fully qualified domain name (FQDN) of the domain. You create this junction point under <NewLocationForSYSVOL>\sysvol. The junction point must point to <NewLocationForSYSVOL>\domain. If you move the tree or if hardware reconfiguration results in a change in the drive letter, you must recreate the SYSVOL junction point for the new location. To perform this procedure, you can use the Mklink.exe command-line tool, which is included with Windows Server 2008. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create the sysvol root junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click 145

Continue. 2. At the command prompt, change the directory to the new sysvol root location, for example, FolderName\SYSVOL\sysvol. 3. To create the junction point for the sysvol root, at the command prompt, type the following command, and then press ENTER:
mklink /J <FQDN> <New sysvol root junction path>

Example: mklink
Parameter

/J contoso.com D:\ContosoRoot\SYSVOL\domain

Definition

mklink /J <FQDN> <New sysvol root junction path>

Creates a junction point for the specified domain in the specified path location. The fully qualified domain name of the SYSVOL domain The drive letter and path to the SYSVOL root, for example, Drive:\FolderName\SYSVOL\domain or Drive:\FolderName\SYSVOL_DFSR\domain if SYSVOL has been migrated from File Replication Service (FRS) to Distributed File System (DFS) Replication

4. To verify the creation of the junction point, at the command prompt, type the following command, and then press ENTER:
dir /a:L

Verify the presence of the <JUNCTION> folder type and the value that you specified in step 3.

Start the DFS Replication Service and Netlogon Service
After you relocate the SYSVOL tree or the SYSVOL staging area, or both, use this procedure to restart the Distributed File System (DFS) Replication service, the Netlogon service, or both. After you restart the service or services, review the event log to ensure that the services restarted successfully. You can use the Windows graphical user interface (GUI) or the command line to start the DFS Replication service and the Netlogon service.

146

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To start the DFS Replication service or Netlogon service, or both, by using the Windows GUI 1. On the Start menu, point to Administrative Tools and then click Services. 2. In the Name column, right-click DFS Replication or Netlogon, and then click Restart. To start the DFS Replication service or Netlogon service, or both, by using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. To start the DFS Replication service, at the command prompt, type the following command, and then press ENTER:
net start dfsr

3. To start the Netlogon service, at the command prompt, type the following command, and then press ENTER:
net start netlogon

Notes • You can use Event Viewer to verify that DFS Replication restarted correctly. In the DFS Replication log (in Applications and Services Logs), Event ID 1004 indicates that the service restarted. Look for Event IDs 1210, 1206, and 6102 to verify that the domain controller is running and ready for service. If you moved SYSVOL to a new location or relocated the staging areas folder, look for Event IDs 4604 and 6018, which indicate success. Event ID 7036 in the System event log reports that the Netlogon service is running. This event reports on all services that are stopped or started. • Also verify that the Netlogon service is sharing the sysvol (SYSVOL share) and scripts (NETLOGON share) folders. At a command prompt, type net share, and then press ENTER.

Restoring and Rebuilding SYSVOL
A domain controller cannot function without a properly shared and replicating SYSVOL. If your efforts to move SYSVOL or perform certain maintenance tasks fail and SYSVOL is not replicating, you must recreate (rebuild) SYSVOL on the domain controller. Attempt to rebuild SYSVOL on a domain controller only when all other domain controllers in the domain have a healthy and

147

functioning SYSVOL. Do not attempt to rebuild SYSVOL until you correct any problems that may be occurring with Distributed File System (DFS) Replication in a domain. Use the procedures in this section only on a domain controller that does not have a functioning SYSVOL. Task requirements The following tools are required to perform the procedures for this task: • • • • • • • • Active Directory Sites and Services Event Viewer Dcdiag.exe ADSI Edit Net.exe Regedit.exe Windows Explorer Mklink.exe

To complete this task, perform the following procedures in order: 1. Identify Replication Partners You will import the SYSVOL from a replication partner. 2. Check the Status of the SYSVOL and Netlogon Shares Perform this procedure on the replication partner from which you are copying SYSVOL to make sure that the SYSVOL tree that you copy from the partner is shared and replicating properly. 3. Verify Active Directory Replication Verify that replication is working on both replication partners. 4. Gather the SYSVOL Path Information 5. Restart the domain controller in Directory Services Restore Mode (DSRM) by using one of the following methods: • Restart the Domain Controller in Directory Services Restore Mode Locally If you are sitting at the console of the domain controller, restart the domain controller locally in DSRM. • Restart the Domain Controller in Directory Services Restore Mode Remotely If you are accessing the domain controller remotely using Remote Desktop Connection, restart the domain controller remotely in DSRM. 6. Stop the DFS Replication Service and Netlogon Service In DSRM, the DFS Replication service is stopped automatically. You have to stop only the Netlogon service. Both services restart automatically when you restart the domain controller normally after you complete the procedure to import the SYSVOL folder structure. 7. Import the SYSVOL Folder Structure 8. Check the Status of the SYSVOL and Netlogon Shares

148

Identify Replication Partners
You can use this procedure to examine the connection objects for a domain controller and identify its replication partners. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To identify replication partners 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, double-click 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 then determine the site association. 4. Double-click the Servers folder to display the list of servers in that site. 5. Double-click the server object for the domain controller whose replication partners you want to identify to display its NTDS Settings object. 6. Click the NTDS Settings object to display the list of connection objects in the details pane. (These objects represent inbound connections that are used for replication to the server.) The From Server column displays the names of the domain controllers that are source replication partners for the selected server object.

Check the Status of the SYSVOL and Netlogon Shares
You can use this procedure to make sure that the Distributed File System (DFS) Replication service is started properly and then ensure that the sysvol shared folder and netlogon (scripts) shared folder are created and shared. For information about checking SYSVOL status for File Replication Service (FRS), see the Windows Server 2003 topic Check the status of the shared SYSVOL (http://go.microsoft.com/fwlink/?LinkId=120774).

149

Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To check the status of the SYSVOL and Netlogon shares 1. On the Start menu, point to Administrative Tools, and then click Services. 2. Verify that the DFS Replication service and the Netlogon service have a status of Started. If a service is stopped, click Restart. 3. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 4. To verify that the SYSVOL tree includes the sysvol and scripts shared folders, at the command prompt, type the following command, and then press ENTER:
net share

5. Check the list to be sure that it includes %systemroot%\SYSVOL\sysvol\ (the SYSVOL share) and %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS (the NETLOGON share), where <Domain Name> is the domain of the new domain controller. Note If neither %systemroot%\SYSVOL\sysvol\ nor %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS are present, see Verify Active Directory Replication. 6. Verify that the proper permissions are set for SYSVOL replication. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:netlogons

Look for a message that states that <ComputerName> passed test NetLogons, where <ComputerName> is the name of the domain controller. If you do not see the “passed test” message, check the permissions that are set on the Scripts and Sysvol shared folders. For information about default SYSVOL permissions, see Reapply Default SYSVOL Security Settings.

Verify Active Directory Replication
You can use this procedure to verify that Active Directory replication is functioning properly on a domain controller. Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

150

To verify Active Directory replication 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:replications

Note For more detailed replication information, use the /v option. If this test fails, open Event Viewer and check for errors in the Directory Service log. Use the information in the ActiveDirectory_DomainService replication events to troubleshoot the problem.

Gather the SYSVOL Path Information
When you relocate the SYSVOL tree or staging areas subtree, it is helpful to record the current and new values for the path locations in the SYSVOL tree that are required for SYSVOL to function. By recording these values in advance, you can facilitate the move process. When you move SYSVOL, you first copy the folder structure to a new location. Then, you update the locations where folder paths are specified: junction points in the file system, Netlogon parameters in the registry, and attributes in Active Directory Domain Services (AD DS). As an option, you can relocate the staging areas subtree and leave the rest of the SYSVOL tree at its original location. In this case, you must update an attribute in AD DS, but the junction point for the staging areas folder is updated automatically. You also have to record this path information when you are rebuilding SYSVOL on one domain controller by importing the SYSVOL of another domain controller. Note The instructions in this procedure relate to domains in which Distributed File System (DFS) Replication is used to replicate SYSVOL. For information about relocating SYSVOL when you use File Replication Service (FRS), see Relocating SYSVOL Manually (http://go.microsoft.com/fwlink/?LinkId=122590). For more information about the folder structure and the relationships between the folders and the path information that is stored in the registry, AD DS, and the SYSVOL directory itself, see Introduction to Administering DFS-Replicated SYSVOL. You can use these procedures to locate the SYSVOL path information and then record the values in the following table. Use the rows and columns in the table according to the goals of your procedure. Record the current values and also the new values if you are moving the SYSVOL tree or the staging areas subtree or if you are rebuilding SYSVOL: 151

• Relocating the entire SYSVOL tree: Record the current and new path values in rows 1 through 5. • Relocating the staging areas subtree only: Record the current and new path values in rows 2 and 5. • Restoring and rebuilding SYSVOL: Record path information as follows: • Record the current values from the domain controller that you are restoring in rows 1, 2, and 3. • In the Current Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller from which you are copying the SYSVOL folder structure. • In the New Value column in rows 4 and 5, record the values in the junction points that are located on the domain controller whose SYSVOL you are rebuilding.
Parameter Current value New value

1 2 3 4 5

msDFSR-RootPath in AD DS msDFSR-StagingPath in AD DS SysVol Netlogon parameter in the registry Sysvol junction point Staging areas junction point

To gather the SYSVOL path information
Perform the following procedures to gather values for SYSVOL paths and record the data in the preceding table. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the msDFSR-RootPath and the msDFSR-StagingPath values in AD DS 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 2. Right-click ADSI Edit, and then, if the domain whose path information you want to check is not listed, click Connect to. 3. Under Connection Point, click Select a well known Naming Context, click Default naming context, and then click OK. 4. In the tree view, expand the domain component, and then expand OU=Domain 152

Controllers. 5. Double-click the container that represents a domain controller on which you can check the path information, double-click CN=DFSR-LocalSettings, and then click CN=Domain System Volume. 6. In the details pane, right-click CN=SYSVOL Subscription, and then click Properties. 7. Click Filter. Ensure that Show mandatory attributes is selected. Select this option if it is not selected. 8. In Attributes, locate msDFSR-RootPath and msDFSR-StagingPath, and then record the current values in rows 1 and 2, respectively, in the previous table. If you are moving SYSVOL, also record the new values for the new location in both rows. If you are moving the staging areas subtree, record the new path value in row 2. 9. Click Cancel to close the CN=Subscription Properties dialog box. To determine the SysVol Netlogon parameter value 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\Parameters. 3. In the details pane, double-click SysVol. The current value is listed in Value data. 4. Record the current value in row 3 of the previous table, and then click Cancel to close the Edit String dialog box. If you are moving SYSVOL, also record the new value for the new location. 5. Close Registry Editor. To determine the value in the sysvol junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\sysvol, or to the current location if SYSVOL has been moved from the default location. 3. To view the junction point for the sysvol folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. Record the current value in row 4 in the previous table. If you are moving SYSVOL, also record the new value for the new location. To determine the value in the staging areas junction point 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click 153

Continue. 2. At the command prompt, change the directory to %systemroot%\SYSVOL\staging areas or to the current location if the staging areas subtree has been moved from the default location. 3. To view the junction point for the staging areas folder, at the command prompt, type the following command, and then press ENTER:
dir /a:L

4. The output identifies the <JUNCTION> folder type and the value that is stored in the staging areas junction point in brackets. For example, the default value is [Drive:\ %systemroot%\SYSVOL\staging\domain] (or, if SYSVOL has been migrated from FRS to DFS Replication, [Drive:\%systemroot%\SYSVOL_DFSR\staging\domain]). Record the current value in row 5 of the previous table. If you are moving SYSVOL or the staging areas subtree, also record the new value for the new location.

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 (DSRM) locally. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not as a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Stepby-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). You can restart a domain controller in DSRM manually by pressing the F8 key during domain controller startup, which requires watching the startup and waiting for the appropriate point in the startup to press the key. This method is tedious and can waste time if you miss the brief window of opportunity for selecting the restart mode. On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration 154

parameters and controls. You can use the Windows graphical user interface (GUI) or the command line to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. When you are finished managing a domain controller in DSRM, if you have used System Configuration or Bcdedit.exe to restart the domain controller in DSRM, you must change the configuration so that the domain controller restarts in normal mode. Note A benefit of using System Configuration or Bcdedit.exe for implementing restart of a domain controller into DSRM is that normally the domain controller cannot be inadvertently restarted. This benefit is particularly useful when you are performing a nonauthoritative restore from backup followed by an authoritative restore. You can also use System Configuration or Bcdedit.exe to restart a domain controller in DSRM remotely. To use System Configuration or Bcdedit.exe and Remote Desktop Connection to restart a domain controller in DSRM remotely, see Restart the Domain Controller in Directory Services Restore Mode Remotely. Membership in the Domain Admins group is the minimum required complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM is required to log on to the domain controller in DSRM. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728).

Restarting the domain controller in DSRM locally
You can use either of the following methods to restart the domain controller in DSRM: To restart a domain controller in DSRM locally by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click System Configuration. 2. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 3. In the System Configuration dialog box, click Restart. The domain controller restarts 155

in DSRM. 4. Perform procedures in DSRM. 5. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. To restart a domain controller in DSRM locally by using the command line 1. Click Start, click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

4. When you are still in DSRM and you are ready to restart in normal mode, open a command prompt and type the following, and then press ENTER:
bcdedit /deletevalue safeboot

5. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

Value

Description

/set safeboot dsrepair shutdown –t 0 -r /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Restart the Domain Controller in Directory Services Restore Mode Remotely

156

Restart the Domain Controller in Directory Services Restore Mode Remotely
If you have remote access to a domain controller, you can restart the domain controller in Directory Services Restore Mode (DSRM) remotely. Remote access requires the user right to log on locally to a domain controller. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line or to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. To restart the domain controller in DSRM remotely, you first use Remote Desktop Connection to connect to the domain controller while it is in normal startup mode. Remote Desktop Connection must be enabled on the target domain controller. After the domain controller has restarted, you can use Remote Desktop Connection to reconnect to the domain controller and then log on as the local Administrator, using the DSRM password. You can use this procedure to connect to a domain controller remotely, restart it in DSRM, and then reconnect to it as the DSRM administrator. Membership in Domain Admins, or equivalent, is the minimum required to complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM and the user right to log on locally to a domain controller are required to log on to the domain controller in DSRM. Members of Account Operators, Administrators, Enterprise 157

Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the user right to log on locally to a domain controller by default. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. Using a domain administrative account to log on to an RODC can compromise the server. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). To restart a domain controller in DSRM remotely by using the Windows GUI 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. On the Start menu, point to Administrative Tools, and then click System Configuration. 3. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 4. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 5. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 6. The domain controller name should still be showing in Computer. If it is not, select it from the list, and then click Connect. 7. In the Windows Security dialog box, click Use another account. 8. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 9. In Password, type the DSRM password, and then click OK. 10. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 11. Type MachineName\Administrator, and then press ENTER. 158

12. Perform procedures in DSRM. 13. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. This procedure will disconnect your remote session. To restart a domain controller in DSRM remotely by using the command line 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. Open a command prompt. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 4. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 5. The domain controller name should still be showing in Computer. If it is not, select it in the list, and then click Connect. 6. In the Windows Security dialog box, click Use another account. 7. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 8. In Password, type the DSRM password, and then click OK. 9. At the logon screen of the remote domain controller, click Switch User, and then click Other User.

159

10. Type MachineName\Administrator, and then press ENTER. 11. Perform procedures in DSRM. 12. When you have finished performing procedures in DSRM, restart the domain controller normally: a. In DSRM, open a command prompt, type the following command, and then press ENTER:
bcdedit /deletevalue safeboot

b. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 –r

The domain controller restarts normally. This procedure will disconnect your remote session.
Value Description

bcdedit /set safeboot dsrepair shutdown –t 0 -r bcdedit /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Enable Remote Desktop Create a Remote Desktop Connection Restart the Domain Controller in Directory Services Restore Mode Locally

Stop the DFS Replication Service and Netlogon Service
You can use this procedure to stop the Distributed File System (DFS) Replication service and the Netlogon service when you are performing offline updates to the SYSVOL tree. The Netlogon service advertises the server as a domain controller by sharing out the SYSVOL folder. The services must be turned off until updates to the SYSVOL path information are complete and the SYSVOL junction point has been updated for the new location. You can use the Windows graphical user interface (GUI) or the command line to stop the DFS Replication service and the Netlogon service. Note The staging path junction point is updated automatically when DFS Replication is restarted.

160

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To stop the DFS Replication service or Netlogon service, or both, by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click Services. 2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop. To stop the DFS Replication service and the Netlogon service by using the command line 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop dfsr

3. At the command prompt, type the following command, and then press ENTER:
net stop netlogon

After you move or restore SYSVOL, when you update the SYSVOL Netlogon path in the registry, you must also update the SysvolReady parameter in Netlogon parameters, as described in Change the SYSVOL Netlogon Parameters.

Import the SYSVOL Folder Structure
If a domain controller has a nonfunctioning SYSVOL, you can use this procedure to rebuild SYSVOL on the domain controller by copying the SYSVOL folder structure on another domain controller and importing it to the offline domain controller, which cannot operate as a domain controller without a functioning SYSVOL. To properly import SYSVOL, you must copy the SYSVOL folder and its contents. In this procedure, you copy an existing SYSVOL folder structure on a healthy, online domain controller to the target domain controller, which has a failed SYSVOL. After you delete the failed SYSVOL folder, you copy the healthy SYSVOL folder structure to the same location as the original (deleted) SYSVOL folder. This procedure has the following preliminary requirements: • You have identified a replication partner domain controller whose SYSVOL folder structure you will copy. • You have restarted the domain controller to which you are importing SYSVOL in Directory Services Restore Mode (DSRM).

161

• You have stopped the Netlogon service on the target domain controller after restarting the domain controller in DSRM. The Distributed File System (DFS) Replication service is stopped automatically when you restart the domain controller in DSRM. • 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 ADMIN$. Note To view the shared folders to see whether ADMIN$ is shared, on the source domain controller, open Server Manager. In the navigation pane for the domain controller, view Roles and File Services, and then click Share and Storage Management. As an alternative, you can open a command prompt and type net share at the command prompt. • If the ADMIN$ share has been renamed, use the name that is assigned by your organization instead of ADMIN$ as you complete this procedure. • You have determined the target domain controller values for rows 4 (Sysvol junction point) and 5 (Staging areas junction point) in the table you that created in Gather the SYSVOL Path Information. This procedure has the following follow-up requirements: • If you share the %systemroot% folder on the source domain controller to complete this procedure, be sure to remove the share after the procedure is complete to maintain any security policies that are established on your network. • On the target domain controller, perform the verification tests in Check the Status of the SYSVOL and Netlogon Shares. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure on the domain controller from which you are copying SYSVOL. The DSRM administrator password is the minimum required to complete this procedure on the controller to which you are importing SYSVOL. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To import the SYSVOL folder structure 1. On the domain controller to which you are importing the SYSVOL folder structure, open Windows Explorer. 2. Navigate to the existing SYSVOL folder that you are rebuilding, and then delete it. 3. Map a network drive to the ADMIN$ shared directory on the domain controller that you identified earlier as the replication partner from which you plan to copy the SYSVOL folder structure. 4. When you are connected to the ADMIN$ share, verify that a folder labeled SYSVOL appears. Right-click the SYSVOL folder, and then click Copy. 5. In the same ADMIN$ shared directory, right-click some blank space, and then click Paste. 162

6. Verify that the original SYSVOL folder and a new folder labeled SYSVOL – Copy both appear. Right-click SYSVOL - Copy, and then click Rename. Type SYSVOL2, and then press ENTER. 7. Open a Command Prompt. At the 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 /a:L, and then press ENTER. Verify that <JUNCTION> appears in the command output and that it is followed by the name of the domain. 10. You must update the path in this junction point so that it references the new location on the target domain controller. At the command prompt, type the following command, and then press ENTER:
mklink <FQDN> <newpath>

Where <FQDN> is the fully qualified domain name (FQDN) and <newpath> is the new value that you recorded in row 4 of the table in Gather the SYSVOL Path Information. 11. If the staging areas subfolder has been relocated and it is no longer inside the SYSVOL folder, skip steps 11 and 12, and proceed to step 13. If the staging areas subfolder has not been relocated, 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 output of the dir command. 12. Update the junction so that it points to the new location on the target domain controller. At the command prompt, type the following command, and then press ENTER:
linkd <junctionname> <newpath>

Where <newpath> is the new value that you recorded in row 5 of the table in Gather the SYSVOL Path Information. 13. At the command prompt, change back to the %systemroot% directory for the domain controller that is receiving the imported SYSVOL. 14. At the command prompt, use the robocopy command-line tool to copy the contents of the \SYSVOL2 folder that you created to a new SYSVOL folder on your local drive. At the command prompt, type the following command, and then press ENTER:
robocopy <Source Folder> <Destination Folder> /copyall /mir /b /r:0 /xd "DfsrPrivate" /xf "DfsrPrivate"

163

Parameter

Description

<Source Folder> <Destination Folder>

Drive letter and path to the SYSVOL2 directory on the source domain controller. Drive letter and path to the parent location of the SYSVOL folder that you deleted in step 2 on the local domain controller. For example, if you deleted the original SYSVOL folder from C:\Windows\SYSVOL, the path in <Destination Folder> is C:\Windows. Copies the following file information: data, attributes, time stamps, NTFS access control list (ACL), owner information, and auditing information. Mirrors the directory tree that you are copying. Copies files in backup mode. Backup mode allows Robocopy to override file and folder permission settings (ACLs). Specifies performing 0 (zero) retries on failed copies. Excludes the DfsrPrivate directory from the copy. Excludes the DfsrPrivate file from the copy.

/copyall

/mir /b

/r:0 /xd "DfsrPrivate" /xf "DfsrPrivate"

15. Verify that the folder structure copied correctly. Compare the new folder structure to the SYSVOL (not SYSVOL2) folder structure on the remote (source) domain controller. Open a command prompt, and type dir /s to list the contents of the folders and subfolders. Ensure that all folders exist. 16. Delete the SYSVOL2 folder that you created on the remote domain controller. 17. If you shared the %systemroot% folder and created an ADMIN$ share on the remote domain controller, remove the ADMIN$ share. Disconnect from the remote domain controller. 18. Restart the domain controller in normal mode. When you restart the domain controller, the Netlogon service and the DFS Replication service start automatically.

See Also
Check the Status of the SYSVOL and Netlogon Shares 164

Administering the Global Catalog
This guide provides information about administering the global catalog for Active Directory Domain Services (AD DS) in Windows Server 2008. In this guide • • Introduction to Administering the Global Catalog Managing the Global Catalog

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 2008, Windows Server 2003, or Windows 2000 native). When universal groups are available in a domain, a domain controller must be able to locate a global catalog server to process a logon request.

Global catalog hardware requirements
Minimum hardware requirements for global catalog servers depend on the number of users in the site. For disk space requirements and directory database storage guidelines, see Planning Domain Controller Capacity (http://go.microsoft.com/fwlink/?LinkId=80404).

Global catalog placement
In most cases, we recommend that you include the global catalog when you install new domain controllers. The following exceptions apply: Limited bandwidth: In remote sites, if the wide area network (WAN) link between the remote site and the hub site is limited, you can use universal group membership caching in the remote site to accommodate the logon needs of users in the site. For information about universal group membership caching, see Enabling Universal Group Membership Caching in a Site. Infrastructure operations master role incompatibility: Do not place the global catalog on a domain controller that hosts the infrastructure operations master role in the domain unless all domain controllers in the domain are global catalog servers or the forest has only one domain.

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

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 you add the first global catalog server in the site. The impact of this replication varies, depending on the following conditions: • • The speed and reliability of the 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 Domain Name System (DNS) servers can locate it as a global catalog server. Several conditions must be met before the global catalog server is locatable by 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 occupancy moves to the next level. By default, domain controllers running Windows Server 2008 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. For more information about global catalog readiness and occupancy levels, see How the Global Catalog Works (http://go.microsoft.com/fwlink/?LinkID=107063). In summary, a global catalog server is ready to serve clients when the following events occur, in this order: • The global catalog receives replication of read-only replicas to the required occupancy level. • The isGlobalCatalogReady rootDSE attribute is set to TRUE. • The Net Logon service on the domain controller has updated DNS with global-catalogspecific service (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 from a domain controller, that domain controller immediately stops advertising in DNS as a global catalog server. The Knowledge Consistency Checker (KCC) gradually removes the read-only replicas from the domain controller. On domain controllers running Windows Server 2008 or Windows Server 2003, the global catalog, partial, read-only directory partitions are removed in the background, and they receive a low priority so that high-priority services are not interrupted.

166

You might decide to remove the global catalog from a domain controller if universal group membership caching is adequate to satisfy logon requirements in a particular site where WAN link speeds are not adequate for the global catalog. For more information, see Enabling Universal Group Membership Caching in a Site. For more information about global catalog removal, see How the Global Catalog Works (http://go.microsoft.com/fwlink/?LinkID=107063).

Managing the Global Catalog
Designate global catalog servers to accommodate users in sites where a global catalog server is required, for example, to accommodate forest-wide directory searching and to facilitate domain client logons when universal groups are available. For information about global catalog servers, see How the Global Catalog Works (http://go.microsoft.com/fwlink/?LinkId=107063). This section includes the following tasks for managing the global catalog: • • • 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 Knowledge Consistency Checker (KCC) to update the topology. After the topology is updated, 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 167

4. Verify Successful Replication to a Domain Controller

Determine Whether a Domain Controller Is a Global Catalog Server
You can use the setting on the NTDS Settings object to determine whether a domain controller is designated as a global catalog server. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure when you perform the procedure remotely by using Remote Server Administration Tools (RSAT). Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine whether a domain controller is a global catalog server 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, expand the Sites container, expand the site of the domain controller that 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
You use this procedure to designate a domain controller as a global catalog server. When you designate a domain controller as a global catalog server, a partial, read-only directory partition for each domain in the forest, other than the full, writable directory partition of the local domain, is replicated to create the global catalog instance on the server. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To designate a domain controller to be a global catalog server 1. Click Start, point to Administrative Tools, and then click Active Directory Sites and Services. 168

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
You can monitor inbound replication progress to see the percentage of completeness of partial, read-only, directory partition replication to the new global catalog server. Note Although you can change occupancy level requirements for global catalog advertisement to force advertisement to occur before full replica occupancy, doing so can cause e-mail and search issues. Exchange servers use the global catalog for Address Book lookup. 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 e-mail delivery problems for Exchange clients. Membership in Domain Users and the right to log on locally to the domain controller is the minimum required to complete this procedure. By default, members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the right to log on locally to a domain controller. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To monitor global catalog replication progress 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
dcdiag /s:<servername> /v | find "%"

Parameter

Description

s:<servername> /v | find "%"

Specifies the name of the global catalog server that you want to monitor. Finds the percentage of replication, and provides extended information. 169

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

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. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify successful replication to a domain controller 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl <servername> /u:<domainname>\<username> /pw:*

Note The user credential parameters (/u:<domainname>\<username> /pw:*) are not required for the domain of the user if the user has opened the Command Prompt as an administrator with Domain Admins credentials or is logged on to the domain controller as a member of Domain Admins or equivalent. However, if you run the command for a domain controller in a different domain in the same Command Prompt session, you must provide credentials for an account in that domain.

170

Value

Description

repadmin /showrepl

Displays the replication status for the last time that the domain controller that is named in <servername> attempted inbound replication of Active Directory partitions. The name of the destination domain controller. Specifies the domain name and user name, separated by a backslash, for a user who has permissions to perform operations in AD DS. 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.) The name of an administrative account in that domain. Specifies the domain password for the user named in <username>. * provides a Password: prompt when you press ENTER.

<servername> /u:

<domainname>

<username> /pw:*

3. At the Password: prompt, 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 Microsoft Excel 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 creates this spreadsheet and sets column headings for improved readability.

171

To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv >showrepl.csv

3. Open Excel. 4. Click the Office button, 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. • Or • To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top Row. 8. Select the entire spreadsheet. On the Data tab, click Filter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the filter down arrow, point to Text Filters, and then click Custom Filter. 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 11 for the Last Failure Time column, but use the value does not equal, and then 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 (http://go.microsoft.com/fwlink/?LinkID=93582): • • • The last successful intersite replication was before the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful. To hide the column, right-click the column, and then click Hide.

172

Determining Global Catalog Readiness
After replication of the partial domain directory partitions is complete, the domain controller advertises itself as a global catalog server and begins accepting queries. Advertising begins when the occupancy level for partial domain directory partition replication has been reached. The default occupancy level requires that all partial domain directory partitions have been replicated. Caution If you lower the occupancy level, the domain controller advertises itself as a global catalog server before it has complete information from all domains in the forest. In this case, it might return false information to applications that begin using the server for Address Book lookup and forest-wide searches. You can use the procedures in this task to determine if a domain controller is ready to begin advertising itself as a global catalog server. Task requirements The following tools are required to perform the procedures for this task: • • • Ldp.exe Nltest.exe DNS snap-in

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. You can use this procedure to verify global catalog readiness. Membership in Domain Users and the right to log on locally to a domain controller is the minimum required to complete this procedure. By default, members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the right to log on locally to a domain controller. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Verifying global catalog readiness
• • Using the Windows interface Using a command prompt

173

To verify global catalog readiness using the Windows interface 1. Click Start, click Run, type Ldp, and then click OK. 2. On the Connection menu, click Connect. 3. In Connect, type the name of the server whose global catalog readiness you want to verify. 4. In Port, if 389 is not showing, type 389. 5. If the Connectionless check 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. To verify global catalog readiness using a command prompt 1. Open a Command Prompt. 2. At the command prompt, type the following command, and then press ENTER:
nltest /server:<servername> /dsgetdc:<domainname>

Parameter

Description

<servername>

Specifies the name of the domain controller that 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, 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, confirm the presence of Domain Name System (DNS) service (SRV) resource records for the server. You can use this procedure to verify global catalog DNS registrations. Membership in DNSAdmins and the right to log on locally to the domain controller is the minimum required to complete this procedure. By default, members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the right to log on locally to a domain controller. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

174

To verify global catalog DNS registrations 1. Click Start, point to Administrative Tools, and then click DNS. 2. Connect to a domain controller in the forest root domain: Right-click DNS, click Connect to DNS Server, and then click The following computer. Type the computer name, and then click OK. 3. Expand Forward Lookup Zones, and then expand the forest root domain. 4. Click the _tcp container. 5. 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 service (SRV) resource 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 in Active Directory Sites and Services. As soon as this operation is complete, the domain controller stops advertising itself as a global catalog server (that is, Net Logon deregisters the global-catalog-related records in Domain Name System (DNS)), and the domain controller immediately stops accepting Lightweight Directory Access Protocol (LDAP) requests over ports 3268 and 3269. Global catalog directory partitions are removed gradually in the background. 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 begins the removal of the partial, read-only directory partitions from the directory database of the domain controller. You can use this procedure to clear the global catalog setting. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

175

To clear the global catalog setting 1. Click Start, point to Administrative Tools, and then click 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 from which you want to remove the global catalog. 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. When the global catalog has been removed successfully, the Knowledge Consistency Checker (KCC) logs Event ID 1268 in the Directory Service event log. You can use this procedure to monitor global catalog removal in Event Viewer. Membership in Server Operators and the right to log on locally to a domain controller, or equivalent, is the minimum required to complete this procedure. By default, members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the right to log on locally to a domain controller. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To monitor global catalog removal in Event Viewer 1. Click Start, point to Administrative Tools, and then 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, and then type the name of the server from which you removed the global catalog. 4. Click Connect as another user, and then click Set User. 5. Type the user name and password for a user that has access to the global catalog server and permission to open Event Viewer, and then click OK twice. 6. Under Applications and Services Logs, click Directory Service. 7. Look for ActiveDirectory_DomainService event ID 1268, which indicates that the global catalog is removed from the local computer.

176

Administering Operations Master Roles
This guide provides information about administering Active Directory operations master (also known as flexible single master operations or FSMO) roles in Windows Server 2008. In this guide • • Introduction to Administering Operations Master Roles Managing Operations Master Roles

Introduction to Administering Operations Master Roles
Domain controllers that hold operations master (also known as flexible single master operations or FSMO) roles 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 operations master. The PDC emulator operations master processes all replication requests from Windows NT Server 4.0 backup domain controllers (BDCs). It also processes all password updates for clients not running Active Directory–enabled client software, plus any other directory write operations. The PDC emulator receives preferential replication of password changes that are performed by other domain controllers in the domain, and it is the source for the latest password information whenever a logon attempt fails as a result of a bad password. For this reason, of all operations master roles, the PDC emulator operations master role has the highest impact on the performance of the domain controller that hosts that role. The PDC emulator in the forest root domain is also the default Windows Time service (W32time) time source for the forest. • The relative ID (RID) operations 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 operations master. The infrastructure master manages references from objects in its domain to objects in other domains. It also updates group-to-user references when the members of groups are renamed or changed. In addition to the three domain-level operations master roles, two operations master roles exist in each forest: • The schema operations master. The schema master governs all changes to the schema. • The domain naming operations master. The domain naming master adds and removes domain directory partitions and application directory partitions to and from the forest. To perform their respective operations, the domain controllers that host operations master roles must be consistently available and they must be located in areas where network reliability is high.

177

Careful placement of your operations masters becomes more important as you add more domains and sites as you build your forest.

Guidelines for role placement
Improper placement of operations master role holders can prevent clients from changing their passwords or being able to add domains and new objects, such as Users and Groups. Schema changes might not be possible. In addition, name changes might appear improperly within group memberships that are displayed in the user interface (UI). Note Operations master roles cannot be placed on a read-only domain controller (RODC). As your environment changes, you must avoid the problems that are associated with improper operations master role placement. Eventually, you might have 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, improper infrastructure master role placement can cause the infrastructure master to perform incorrectly. Other improper operations master configurations can increase administrative overhead. Following these guidelines will help to minimize administrative overhead and ensure the proper performance of Active Directory Domain Services (AD DS). Following these guidelines will simplify the recovery process if a domain controller that is hosting an operations master role fails. Follow these guidelines for operations master role placement: • Configure an additional domain controller as the standby operations master for the forestlevel roles. Configure an additional domain controller as the standby operations master for the domain-level roles. • • • Place the domain-level roles on a high-performance domain controller. Do not place domain-level roles on a global catalog server. Leave the two forest-level roles on a domain controller in the forest root domain.

• In the forest root domain, transfer the three domain-level roles from the first domain controller that you installed in the forest root domain to an additional domain controller that has a high performance level. • • In all other domains, leave the domain-level roles on the first domain controller. Adjust the workload of the PDC emulator, if necessary.

Prepare additional domain controllers as standby operations masters Because the operations master roles are critical to proper forest and domain function, it is important to be prepared in the event that an operations master role holder becomes inoperable or unreachable. You can prepare an additional domain controller for the forest roles in the forest root domain and an additional domain controller for the domain roles in each domain by configuring them to be optimally connected to the respective current role holder so that role transfer occurs as quickly as possible. Place domain-level roles on a high-performance domain controller 178

The PDC emulator role requires a powerful and reliable domain controller to ensure that the domain controller is available and capable of handling the workload. Of all the operations master roles, the PDC emulator role 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. Note If an RODC is installed in the domain, the PDC emulator role must be placed on a domain controller that is running Windows Server 2008. 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 that holds the PDC emulator role. Again, clients running operating systems earlier than Windows 2000 Server and domain controllers running Windows NT Server 4.0 rely more heavily on the PDC emulator than AD DS clients and domain controllers. If your networking environment has clients and domain controllers running operating systems earlier than Windows 2000 Server, 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 controller’s weight in the Domain Name System (DNS) environment, you can configure the domain controller to receive fewer client requests than other domain controllers on your network. As an option, you can adjust the domain controller’s 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. Do not place domain-level roles on a global catalog server The infrastructure master is incompatible with the global catalog, and it must not be placed on a global catalog server. Because it is best to keep the three domain-level roles together for ease of administration, avoid putting any of them on a global catalog server. The infrastructure master updates objects for any attribute values with distinguished name (dn) syntax that reference objects outside the current domain. These updates are particularly important for security principal objects (users, computers, and groups). For example, suppose a user from one domain is a member of a group in a second domain and the user’s surname (the sn attribute on the user object) is changed in the first domain. This change usually also changes the dn attribute value of the user object, which is the value that is used in the member attribute of group objects. Because domain controllers in one domain do not replicate security principals to domain controllers in another domain, the second domain never receives the change. An out-of-date value on the member attribute of a group in another domain could result in the user whose name has changed being denied privileges. To ensure consistency between domains, the infrastructure master constantly monitors group memberships, looking for member attribute values that identify security principals from other domains. If it finds one, it compares its distinguished name with the distinguished name in the domain of the security principal to determine if the information has

179

changed. If the information on the infrastructure master is out of date, the infrastructure master performs an update and then replicates the change to the other domain controllers in its domain. Two exceptions apply to this rule: 1. If all the domain controllers are global catalog servers, the domain controller that hosts the infrastructure master role is insignificant because global catalog servers replicate updated security principal information to all other global catalog servers. 2. If the forest has only one domain, the infrastructure master role is not needed because security principals from other domains do not exist. Leave forest-level roles on the original domain controller in the forest root domain The first domain controller that is installed in the forest automatically receives the schema master and domain naming master roles. It also hosts the global catalog. To ease administration and backup and restore procedures, leave these roles on the original forest root domain controller. The roles are compatible with the global catalog, and 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. In the forest root domain, transfer domain-level roles from the first domain controller The three domain-level roles are assigned to the first domain controller that is created in a new domain. In the case of the forest root domain, the first domain controller that is created in the domain hosts both forest-level roles and all three domain-level roles, as well as the global catalog. The infrastructure master role is incompatible with the global catalog. For this reason, when you install the second domain controller in the forest root domain, the Active Directory Domain Services Installation Wizard prompts you to allow the wizard to transfer the role during installation of AD DS. Following installation of the second domain controller, consider transferring the PDC emulator and RID master roles to the second domain controller, as well, to keep the three roles together for easy administration. In all other domains, leave domain-level roles on the first domain controller Except for the forest root domain, leave the domain-level roles on the first domain controller that you install in the domain and do not configure that domain controller as a global catalog server. Keep the roles together unless the workload on your operations master justifies the additional management burden of separating the roles. Because all clients running non-Windows operating systems or Windows operating systems earlier than Windows 2000 Server submit updates to the PDC emulator, the domain controller holding that role uses a higher number of RIDs when the network hosts many of these clients. 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. 180

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. Adjust the workload of the PDC emulator operations master role holder Depending on the size of the forest or domain, you might want to configure DNS so that client requests favor domain controllers other than the PDC emulator. The PDC emulator role has the highest load demands of all the operations master roles.

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 is complete, the previous role holder no longer attempts to perform as the operations master, which eliminates the possibility of duplicate operations masters existing on the network. Consider moving the operations master role or roles when any of the following conditions exist: • • • • Inadequate service performance Failure of a domain controller that hosts an operations master role Decommissioning of a domain controller that hosts an operations master role Administrative configuration changes that affect operations master role placement

Inadequate service performance The PDC emulator is the operations master role that most affects 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 it provides support for these clients, the domain controller continues to perform its normal services, such as authenticating Active Directory–enabled clients. As the network grows, the volume of client requests can increase the workload for the domain controller that hosts the PDC emulator role and its performance can suffer. To solve this problem, you can transfer all or some of the operations master roles to another, more powerful domain controller. As an alternative, 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. Operations master failure In the event of a failure of an operations role holder, 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 you take a domain controller offline permanently, transfer any operations master roles that the domain controller holds 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 181

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 operations master 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 the domain controllers in the domain are global catalog servers or unless the forest has only one domain. If the domain controller that hosts 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 to keep them in a particular site. Note Do not change the global catalog configuration on the domain controller that you intend to assume an operations master role unless your information technology (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 configured properly. 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. Reattaching the previous role holder to the network incorrectly 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. This section includes the following tasks for managing operations master roles: • • • • Designating a Standby Operations Master Transferring an Operations Master Role Seizing an operations master role Reducing the Workload on the PDC Emulator Master

182

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 the operations master roles in a domain, or you can designate a separate standby for each operations master role. When you designate a domain controller as the standby operations master, follow all the recommendations in "Guidelines for Role Placement" in Introduction to Administering Operations Master Roles.

Standby operations master computer requirements
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 operations master should be well connected. “Well connected” means that the network connection between them must support at least a 10-megabit transmission rate and be available at all times. In addition, creating a manual connection object between the standby domain controller and the operations master will ensure direct replication between the two operations masters. By making the operations master and the standby operations master direct replication partners, you reduce the chance of data loss in the event of a role seizure, which reduces the chance of directory corruption.

Replication requirements
Before you transfer 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 already consistent with the original operations master, which reduces the time that is 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 have 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. Task requirements The following tools are required to perform the procedures for this task: • • • • • Active Directory Sites and Services Repadmin.exe Determine Whether a Domain Controller Is a Global Catalog Server Create a Connection Object on the Operations Master and Standby Verify Successful Replication to a Domain Controller 183

To complete this task, perform the following procedure:

Determine Whether a Domain Controller Is a Global Catalog Server
You can use the setting on the NTDS Settings object to determine whether a domain controller is designated as a global catalog server. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure when you perform the procedure remotely by using Remote Server Administration Tools (RSAT). Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine whether a domain controller is a global catalog server 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, expand the Sites container, expand the site of the domain controller that 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 Operations Master and Standby
To ensure that the current operations master role holder and the standby operations master are replication partners, you can manually create connection objects between the two domain controllers. Even if a connection object is generated automatically, we recommend that you manually create a connection object on both the operations master and the standby operations master. The replication system can alter automatically created connection objects anytime. Manually created connections remain the same until an administrator changes them. You can use this procedure to create the following: • A manual connection object that designates the standby server as the From Server on the NTDS Settings object of the operations master • A manual connection object that designates the operations master server as the From Server on the NTDS Settings object of the standby server Administrative credentials

184

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create a connection object on the operations master and standby 1. Click Start, point to Administrative Tools, and then click Active Directory Sites and Services. 2. Expand the site name in which the current operations master role holder is located to display the Servers folder. 3. Expand the Servers folder to see a list of the servers in that site. 4. To create a connection object from the standby server on the current operations master, expand the name of the operations master server on which you want to create the connection object to display its NTDS Settings object. 5. Right-click NTDS Settings, click New, and then click Connection. 6. In the Find Active Directory Domain Controllers dialog box, select the name of the standby server from which you want to create the connection object, 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 then click OK. 8. To create a connection object from the current operations master to the standby server, repeat steps 4 through 7, but in step 4, expand the name of the standby server. In step 6, select the name of the current operations master.

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.

185

Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify successful replication to a domain controller 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl <servername> /u:<domainname>\<username> /pw:*

Note The user credential parameters (/u:<domainname>\<username> /pw:*) are not required for the domain of the user if the user has opened the Command Prompt as an administrator with Domain Admins credentials or is logged on to the domain controller as a member of Domain Admins or equivalent. However, if you run the command for a domain controller in a different domain in the same Command Prompt session, you must provide credentials for an account in that domain.
Value Description

repadmin /showrepl

Displays the replication status for the last time that the domain controller that is named in <servername> attempted inbound replication of Active Directory partitions. The name of the destination domain controller. Specifies the domain name and user name, separated by a backslash, for a user who has permissions to perform operations in AD DS. 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.) The name of an administrative account in that domain. Specifies the domain password for the user named in <username>. * provides a Password: prompt when you press ENTER.

<servername> /u:

<domainname>

<username> /pw:*

186

3. At the Password: prompt, 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 Microsoft Excel 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 creates this spreadsheet and sets column headings for improved readability. To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv >showrepl.csv

3. Open Excel. 4. Click the Office button, 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. • Or • To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top Row. 8. Select the entire spreadsheet. On the Data tab, click Filter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the filter down arrow, point to Text Filters, and then 187 To hide the column, right-click the column, and then click Hide.

click Custom Filter. 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 11 for the Last Failure Time column, but use the value does not equal, and then 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 (http://go.microsoft.com/fwlink/?LinkID=93582): • • • The last successful intersite replication was before the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful.

Transferring an Operations Master Role
When you create a new domain, the Active Directory Domain Services Installation Wizard automatically assigns all 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 forestlevel 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 first domain controller that you install to create a new forest is necessarily both a global catalog server and the infrastructure operations master role holder. When you install the second domain controller in the forest root domain, the Active Directory Domain Services Installation Wizard prompts you to transfer the infrastructure master role to the domain controller that you are installing. Select this option to avoid having to transfer the infrastructure operations master role manually. The transfer of forest-level and domain-level operations master roles is performed as needed, and it 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 that is assuming the role is updated. When you transfer domain-level roles, you must determine whether the domain controller that you want to assume an operations master role is a global catalog server. The infrastructure master for each domain must not host the global catalog. Caution Do not change the global catalog configuration on the domain controller that you want to assume an operations master role unless your information technology (IT) management 188

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 operations master
When you follow the recommendations for operations master role placement, the standby operations master is a direct replication partner and it is ready to assume the operations master roles. Remember to designate a new standby operations master for the domain controller that assumes the operations master roles. For more information, see Designating a Standby Operations Master.

Transferring an operations master role when no standby is ready
If 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. If you are transferring the infrastructure master role, make sure that the target domain controller is not a global catalog server. Preparing the future operations master role holder is the same process as preparing a standby operations master. You must manually create a connection object to ensure that the standby operations master is a replication partner with the current role holder and that replication between the two domain controllers is updated. Task requirements The following 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 Verify Successful Replication to a Domain Controller Determine Whether a Domain Controller Is a Global Catalog Server Install the Schema Snap-in Transfer the Schema Master Transfer the Domain Naming Master Transfer the Domain-Level Operations Master Roles View the Current Operations Master Role Holders

To complete this task, perform the following procedure:

189

Install the Schema Snap-in
You can use this procedure to first register the dynamic-link library (DLL) that is required for the Active Directory Schema snap-in. You can then add the snap-in to Microsoft Management Console (MMC). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To install the Active Directory Schema snap-in 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
regsvr32 schmmgmt.dll

3. Click Start, click Run, type mmc, and then click OK. 4. On the File menu, click Add/Remove Snap-in. 5. Under Available snap-ins, click Active Directory Schema, click Add, and then click OK. 6. To save this snap-in, on the File menu, click Save. 7. In the Save As dialog box, do one of the following: • To place the snap-in in the Administrative Tools folder, in File name, type a name for the snap-in, and then click Save. • To save the snap-in in a location other than the Administrative Tools folder, in Save in, navigate to a location for the snap-in. In File name, type a name for the snap-in, and then click Save. Caution Modifying the schema is an advanced operation that is best performed by experienced programmers and system administrators. For detailed information about modifying the schema, see Active Directory Schema (http://go.microsoft.com/fwlink/?LinkId=80809). Additional considerations • To perform the Schmmgmt.dll registration portion of this procedure, you must be a member of the Domain Admins group in the domain or the Enterprise Admins group in the forest, or you must have been delegated the appropriate authority. Adding the Active Directory Schema snapin to MMC requires only membership in the Domain Users group. However, making changes to the schema requires membership in the Schema Admins group. • The Windows Server 2008 Administration Tools Pack cannot be installed on computers running Windows XP Professional or Windows Server 2003.

190

Transfer the Schema Master
You can use this procedure to transfer the schema operations master role if the domain controller that currently hosts the role is inadequate, has failed, or is being decommissioned. The schema master is a forest-wide operations master (also known as flexible single master operations or FSMO) role. Before you perform this procedure, you must identify the domain controller to which you will transfer the schema operations master role. Before you can use the Active Directory Schema snap-in for the first time, you must register it with the system. If you have not yet prepared the Active Directory Schema snap-in, see Install the Schema Snap-in before you begin this procedure. Note You perform this procedure by using a Microsoft Management Console (MMC) snap-in, although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, see Ntdsutil (http://go.microsoft.com/fwlink/?LinkId=120970). For information about the ntdsutil command, you can type ? at the Ntdsutil.exe command prompt. Membership in Schema Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Transfer the schema master 1. Open the Active Directory Schema snap-in. 2. In the console tree, right-click Active Directory Schema, and then click Change Active Directory Domain Controller. 3. In the Change Directory Server dialog box, under Change to, click This domain Controller or AD LDS instance. 4. In the list of domain controllers, click the name of the domain controller to which you want to transfer the schema master role, and then click OK. 5. In the console tree, right-click Active Directory Schema, and then click Operations Master. The Change Schema Master box displays the name of the server that is currently holding the schema master role. The targeted domain controller is listed in the second box. 6. Click Change. Click Yes to confirm your choice. The system confirms the operation. Click OK again to confirm that the operation succeeded. 7. Click Close to close the Change Schema Master dialog box.

191

Transfer the Domain Naming Master
You can use this procedure to transfer the domain naming operations master role if the domain controller that currently hosts the role is inadequate, has failed, or is being decommissioned. The domain naming master is a forest-wide operations master (also known as flexible single master operations or FSMO) role. Before you perform this procedure, you must identify the domain controller to which you will transfer the domain naming operations master role. Note You perform this procedure by using a Microsoft Management Console (MMC) snap-in, although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, see Ntdsutil (http://go.microsoft.com/fwlink/?LinkId=120970). For information about the ntdsutil command, you can also type ? at the Ntdsutil.exe command prompt. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To transfer the domain naming master 1. Open Active Directory Domains and Trusts: On the Start menu, point to Administrative Tools, and then click Active Directory Domains and Trusts. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if required, and then click Continue. 2. In the console tree, right-click Active Directory Domains and Trusts, and then click Change Active Directory Domain Controller. 3. Ensure that the correct domain name is entered in Look in this domain. The available domain controllers from this domain are listed. 4. In the Name column, click the domain controller to which you want to transfer the domain naming master role, and then click OK. 5. At the top of the console tree, 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 domain controller to which you want to transfer the domain naming master 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 that the transfer took place. Click Close to close the Operations Master dialog box.

192

Transfer the Domain-Level Operations Master Roles
You can use this procedure to transfer the following three domain-level operations master (also known as flexible single master operations or FSMO) roles: • • • Primary domain controller (PDC) emulator operations master Relative ID (RID) operations master Infrastructure operations master

You might want to transfer a domain-level operations master role if the domain controller that currently hosts the role is inadequate, has failed, or is being decommissioned. You can transfer all domain roles by using the Active Directory Users and Computers snap-in. Note You perform these procedures by using a Microsoft Management Console (MMC) snap-in, although you can also transfer these roles by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer the operations master roles, see Ntdsutil (http://go.microsoft.com/fwlink/?LinkID=120970.) For information about the ntdsutil command, can also type ? at the Ntdsutil.exe command prompt. Before you perform this procedure, you must identify the domain controller to which you will transfer the operations master role. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To transfer a domain-level operations master role 1. Open Active Directory Users and Computers: On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the top of the console tree, right-click Active Directory Users and Computers, and then click Change Active Directory Domain Controller. 3. Ensure that the correct domain name is entered in Look in this domain. The available domain controllers from this domain are listed. 4. In the Name column, click the name of the domain controller to which you want to transfer the role, and then click OK. 5. At the top of the console tree, right-click Active Directory Users and Computers, and then click Operations Masters. The name of the current operations master role holder appears in the Operations master box. The name of the domain controller to which you want to transfer the role appears in the lower box. 193

6. Click the tab for the operations master role that 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. 7. Repeat steps 5 and 6 for each role that you want to transfer.

View the Current Operations Master Role Holders
To view the current operations master (also known as flexible single master operations or FSMO) role holders, use the Ntdsutil.exe command-line tool with the roles option. This option displays a list of all current role holders. After you transfer an operations master role, use this procedure to verify that the transfer has occurred successfully throughout the domain. To have full effect, the change must replicate to all domain controllers in the domain for a domain-level role and to all domain controllers in the forest for a forest-level role. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To view the current operations master role holders 1. Open Ntdsutil as an administrator: Click Start, and then, in Start Search, type ntdsutil. At the top of the Start menu, right-click ntdsutil, and then click Run as administrator. In the User Account Control dialog box, provide Domain Admins credentials, and then click OK. 2. At the ntdsutil: prompt, type roles, and then press ENTER. 3. At the fsmo
maintenance:

prompt, type connections, and then 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 that contains the operations masters. 5. After you receive confirmation of the connection, type quit, and then press ENTER to exit this menu. 6. At the fsmo ENTER.
maintenance:

prompt, type select

operation target,

and then press and

7. At the select operations target: prompt, type list then press ENTER.

roles for connected server,

The system responds with a list of the current roles and the Lightweight Directory Access Protocol (LDAP) name of the domain controllers that are currently assigned to host each role. 194

8. Type quit, and then press ENTER to exit each prompt in Ntdsutil.exe. At the ntdsutil: prompt, type quit, and then press ENTER to close the window.

Seizing an operations master role
Role seizure is the act of assigning an operations master (also known as flexible single master operations or FSMO) role to a new domain controller without the cooperation of the current role holder—usually, because the current role holder is offline as a result of a hardware failure. During role seizure, the new domain controller assumes the operations master role without communicating with the current role holder. Role seizure should be performed only as a last resort. Role seizure can cause the following directory problems: • Data loss or directory inconsistency as a result of replication latency. The new role holder starts performing its duties based on the data that is located in its current directory partition. If replication did not complete before the time that the original role holder went offline, the new role holder might not have received the latest changes. 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 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. • Two domain controllers performing the same role. Because the original role holder is offline when role seizure occurs, 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 the original role holder 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. If two domain controllers are performing the same operations master role simultaneously, the severity of the effect from duplicate operations master roles varies, depending on the role that was seized. The effect can range from no visible effect to potential corruption of the Active Directory database. Do not allow a former operations master role holder whose role has been seized to return to an online domain controller. Task requirements The following is required to perform the procedures for this task: • • • • Repadmin.exe Ntdsutil.exe Verify Successful Replication to a Domain Controller Seize the Operations Master Role 195

To complete this task, perform the following procedure: Verify replication to the domain controller that will be seizing the role.



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. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify successful replication to a domain controller 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl <servername> /u:<domainname>\<username> /pw:*

Note The user credential parameters (/u:<domainname>\<username> /pw:*) are not required for the domain of the user if the user has opened the Command Prompt as an administrator with Domain Admins credentials or is logged on to the domain controller as a member of Domain Admins or equivalent. However, if you run the command for a domain controller in a different domain in the same Command Prompt session, you must provide credentials for an account in that domain.

196

Value

Description

repadmin /showrepl

Displays the replication status for the last time that the domain controller that is named in <servername> attempted inbound replication of Active Directory partitions. The name of the destination domain controller. Specifies the domain name and user name, separated by a backslash, for a user who has permissions to perform operations in AD DS. 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.) The name of an administrative account in that domain. Specifies the domain password for the user named in <username>. * provides a Password: prompt when you press ENTER.

<servername> /u:

<domainname>

<username> /pw:*

3. At the Password: prompt, 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 Microsoft Excel 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 creates this spreadsheet and sets column headings for improved readability.

197

To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv >showrepl.csv

3. Open Excel. 4. Click the Office button, 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. • Or • To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top Row. 8. Select the entire spreadsheet. On the Data tab, click Filter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the filter down arrow, point to Text Filters, and then click Custom Filter. 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 11 for the Last Failure Time column, but use the value does not equal, and then 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 (http://go.microsoft.com/fwlink/?LinkID=93582): • • • The last successful intersite replication was before the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful. To hide the column, right-click the column, and then click Hide.

198

Seize the Operations Master Role
You can use the Ntdsutil.exe command-line tool to transfer and seize any operations master (also known as flexible single master operations or FSMO) role. You must use Ntdsutil.exe to seize the schema operations master, domain naming operations master, and relative ID (RID) operations master roles. When you use Ntdsutil.exe to seize an operations master role, the tool first attempts a transfer from the current role owner. If the current role owner is not available, the tool seizes the role. When you use 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: command prompt. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To seize an operations master role 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. At the command prompt, type ntdsutil, and then press ENTER. 3. At the ntdsutil: prompt, type roles, and then press ENTER. 4. At the fsmo
maintenance:

prompt, type connections, and then press ENTER.

5. 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 then press ENTER. 6. After you receive confirmation of the connection, type quit, and then press ENTER. 7. Depending on the role that you want to seize, at the fsmo the appropriate command, and then press ENTER.
Role Credentials
maintenance:

prompt, type

Command

Domain naming master Schema master Infrastructure master Primary domain controller (PDC) emulator RID master

Enterprise Admins Enterprise Admins Domain Admins Domain Admins Domain Admins

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 199

fails, some error information appears and the system proceeds with the seizure of the role. After the seizure of the role is complete, a list of the roles and the Lightweight Directory Access Protocol (LDAP) name of the server that currently holds each role appears. During seizure of the relative ID (RID) operations master role, 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 asks for confirmation that you want the seizure of the role to proceed. Click Yes to proceed. 8. Type quit, and then press ENTER. Type quit again, and then press ENTER to exit Ntdsutil.exe.

View the Current Operations Master Role Holders
To view the current operations master (also known as flexible single master operations or FSMO) role holders, use the Ntdsutil.exe command-line tool with the roles option. This option displays a list of all current role holders. After you transfer an operations master role, use this procedure to verify that the transfer has occurred successfully throughout the domain. To have full effect, the change must replicate to all domain controllers in the domain for a domain-level role and to all domain controllers in the forest for a forest-level role. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To view the current operations master role holders 1. Open Ntdsutil as an administrator: Click Start, and then, in Start Search, type ntdsutil. At the top of the Start menu, right-click ntdsutil, and then click Run as administrator. In the User Account Control dialog box, provide Domain Admins credentials, and then click OK. 2. At the ntdsutil: prompt, type roles, and then press ENTER. 3. At the fsmo
maintenance:

prompt, type connections, and then 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 that contains the operations masters. 5. After you receive confirmation of the connection, type quit, and then press ENTER to exit this menu. 6. At the fsmo ENTER.
maintenance:

prompt, type select

operation target,

and then press

200

7. At the select operations target: prompt, type list then press ENTER.

roles for connected server,

and

The system responds with a list of the current roles and the Lightweight Directory Access Protocol (LDAP) name of the domain controllers that are currently assigned to host each role. 8. Type quit, and then press ENTER to exit each prompt in Ntdsutil.exe. At the ntdsutil: prompt, type quit, and then press ENTER to close the window.

Reducing the Workload on the PDC Emulator Master
In addition to processing normal domain controller load from clients, the primary domain controller (PDC) emulator operations master must also process password changes. Of all the operations master (also known as flexible single master operations or FSMO) roles, the PDC emulator master role has the highest impact on the domain controller that hosts that role. To mitigate some of the load that is caused by normal domain controller traffic, you can protect the PDC emulator by configuring Domain Name System (DNS) to distribute some of the normal request load to other domain controllers that are capable of processing the requests. To receive information from the domain, a client uses DNS to locate a domain controller. The client then sends the request to that domain controller. By default, DNS performs rudimentary load balancing. It also randomizes the distribution of client requests so that the requests 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 the duties of the PDC emulator, it can become overloaded, which has a negative impact on its performance. 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, which gives it more time to function as an operations master. This is especially important for the PDC emulator. To reduce the number of client requests that are processed by the PDC emulator, you can change its weight or its priority in the DNS environment.

Changing the weight for DNS service (SRV) resource records in the registry
Changing the weight of a domain controller to a value less than that of other domain controllers reduces the number of clients that Domain Name System (DNS) refers to that domain controller. This value is stored in the LdapSrvWeight registry entry. The default value is 100, but it can range from 0 through 65535. When you lower this value on a domain controller, DNS refers clients to that domain controller less frequently based on the proportion of this value to the value on other domain controllers. For example, to configure the system so that the domain controller that hosts the PDC 201

emulator role receives requests only half as many times as other domain controllers, configure the weight of the domain controller that host the PDC emulator role to be 50. Assuming that other domain controllers use the default weight value of 100, 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.

Changing the priority for DNS service (SRV) resource records in the registry
Changing the priority of a domain controller also reduces the number of client referrals to it. However, rather than reducing access to the domain controller proportionally with regard to the other domain controllers, changing the priority causes Domain Name System (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. This value is stored in the LdapSrvPriority registry entry. The default value is 0, but it can range from 0 through 65535. The client uses the priority value to help determine to which domain controller it sends requests. 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. 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, the clients send requests to the domain controller with the next highest priority. Therefore, raising the value of the LdapSrvPriority registry entry on the PDC emulator can reduce its chances of receiving client requests. 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 Service (SRV) Resource Records in the Registry 2. Change the Priority for DNS Service (SRV) Resource Records in the Registry

202

Change the Weight for DNS Service (SRV) Resource Records in the Registry
You can use this procedure to reduce the workload on the primary domain controller (PDC) emulator operations master by changing the weight for Domain Name System (DNS) service (SRV) resource records in the registry. Caution Registry Editor bypasses standard safeguards, which allows settings that can damage your system or even require you to reinstall Windows. If you must edit the registry, back up critical volumes first. For information about backing up critical volumes, see Administering Active Directory Backup and Recovery. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the weight for DNS service (SRV) resource records in the registry 1. Open Registry Editor as an administrator: Click Start and then, in Start Search, type regedit. At the top of the Start menu, right-click regedit, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. In Registry Editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. 3. Click Edit, click New, and then click DWORD (32-BIT)Value. 4. For the new value name, type LdapSrvWeight, and then press ENTER. 5. Double-click the value name that you just typed to open the Edit DWORD (32-BIT) 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 Registry Editor.

Change the Priority for DNS Service (SRV) Resource Records in the Registry
You can use this procedure to reduce the workload on the primary domain controller (PDC) emulator operations master by changing the priority for Domain Name System (DNS) service (SRV) resource records in the registry.

203

Caution Registry Editor bypasses standard safeguards, which allows settings that can damage your system or even require you to reinstall Windows. If you must edit the registry, back up critical volumes first. For information about backing up critical volumes, see Administering Active Directory Backup and Recovery. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To change the priority for DNS SRV records in the registry 1. Open Registry Editor as an administrator: Click Start and then, in Start Search, type regedit. At the top of the Start menu, right-click regedit, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 2. In Registry Editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. 3. Click Edit, click New, and then click DWORD (32-BIT) Value. 4. For the new value name, type LdapSrvPriority, and then press ENTER. 5. Double-click the value name that you just typed to open the Edit DWORD (32-BIT) 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 Registry Editor.

Administering Active Directory Backup and Recovery
This guide provides information about administering backup and recovery of Active Directory Domain Services (AD DS) in Windows Server 2008. In this guide • Introduction to Administering Active Directory Backup and Recovery [lhsad_ADDS_Ops_5]_ADDS_Ops_5 • Managing Active Directory Backup and Recovery

204

Introduction to Administering Active Directory Backup and Recovery [lhsad_ADDS_Ops_5]_ADDS_Ops_5
Backup of Active Directory Domain Services (AD DS) must be incorporated into your operations schedule for a set of domain controllers that you identify as critical and on which you perform routine, scheduled backup operations. Recovering AD DS is not performed routinely as an operations task; it is performed only when it is made necessary by a failure or other condition from which a domain controller can recover only by restoring the directory to a previous state. Important Restoring from a backup is not always the best or only option to recover AD DS. Do not perform a restore operation to recover a domain controller until you have performed tests to rule out other causes. Restoring from backup is almost always the right solution to recover deleted objects.

Backing up AD DS
Backup procedures have changed in Windows Server 2008, as compared to previous versions of Windows Server. A new backup tool, Windows Server Backup, replaces NtBackup as the tool that you use to back up AD DS. You cannot use Ntbackup to back up servers running Windows Server 2008. In Windows Server 2008, you can perform three types of backup: • • • System state backup, which includes all the files that are required to recover AD DS Critical-volumes backup, which includes all the volumes that contain system state files Full server backup, which includes all volumes on the server

You can use the Windows Server Backup graphical user interface (GUI) to perform critical-volumes backups and full server backups. You can use the Windows Server Backup command-line tool, Wbadmin.exe, to perform all types of backup, including system state backup. For more information about backing up domain controllers, see Backing Up Active Directory Domain Services.

Recovering AD DS
You can recover from Active Directory corruption or inconsistency by performing a restore operation to return AD DS to its state at the time of the latest backup. Restoring from backup as a method of recovering AD DS should not be undertaken as the primary method of recovering from an error or failure condition, but as a last resort. Assuming that a restore operation is appropriate to recover the domain controller, requirements for recovering AD DS relate to the age of the backup, as follows:

205

• The primary requirement for recovering AD DS is that the backup you use must not be older than a tombstone lifetime, which is the number of days that deletions are retained in the directory. In forests that are created on servers running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with SP2, or Windows Server 2008, the default value of the tombstone lifetime is 180 days. The default value is 60 days in forests that are created on servers running Windows 2000 Server or Windows Server 2003. AD DS protects itself from restoring data that is older than the tombstone lifetime by not allowing the restore. Important Always check the tombstone lifetime value before you use a backup to restore AD DS. Even if you are sure of the default value for your environment, the tombstone lifetime value might have been changed administratively in AD DS. Use ADSI Edit to view the value in the tombstoneLifetime attribute on the object CN=Directory Service,CNWindows NT,CN=Services,CN=Configuration,DC=ForestRootDomain. • Do not modify system clocks in an attempt to improperly extend the useful life of a system state backup. Skewed time can cause serious problems in cases where directory data is time sensitive. You can recover AD DS by restoring a backup in the following ways: • Nonauthoritative restore: Use this process to restore AD DS to its state at the time of the backup, and then allow Active Directory replication to update the restored domain controller to the current state of AD DS. • Authoritative restore: Use this process to recover objects that have been deleted from AD DS. Authoritative restore does not allow replication to overwrite the restored deletions. Instead, the restored objects replicate authoritatively to the other domain controllers in the domain. Note Be aware that additions of data that are made between the time of the backup and the authoritative restore process are not removed during the restore process. Authoritative restore focuses only on the deleted objects. Additional data is merged during the restore process. When recovering AD DS by restoring from backup is not possible, you must reinstall AD DS. Sometimes restoring from backup is possible but not feasible. For example, if a domain controller is needed quickly, it is sometimes faster to reinstall AD DS than to recover the domain controller. In cases of hardware failure or file corruption, you might have to reinstall the operating system and then either reinstall or restore AD DS. For more information about rationales and methods for recovering domain controllers, see Recovering Active Directory Domain Services.

Additional considerations
• • Backing Up Active Directory Domain Services Recovering Active Directory Domain Services 206

Managing Active Directory Backup and Recovery
This section includes the following tasks for managing backup and recovery of Active Directory Domain Services (AD DS): • • Backing Up Active Directory Domain Services Recovering Active Directory Domain Services

Backing Up Active Directory Domain Services
This section describes the different types of backups that you can perform to ensure that you can recover Active Directory Domain Services (AD DS) if Active Directory data quality or consistency is jeopardized by human error, hardware breakdown, or software issues. You can perform regular, scheduled backups—which are essential for dependable operations—and you can perform immediate, ad hoc backups when necessary or as an alternative to scheduling regular backups, although scheduling is preferred. Backup tools and processes are improved in Windows Server 2008 to provide easier methods for backing up the data that is required to recover AD DS and the full server.

Windows Server backup tools
To back up AD DS in Windows Server 2008, you use the Windows Server Backup tool. Windows Server Backup replaces the Backup or Restore Wizard (Ntbackup), the tool that is used in earlier versions of the Windows Server operating system. You cannot use Ntbackup to back up servers that are running Windows Server 2008. To use Windows Server Backup tools, you must install Windows Server Backup Features in Server Manager. For information about how to install Windows Server Backup Features, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkId=96495). In the features list in Server Manager, Windows Server Backup Features has two parts: • Windows Server Backup (Wbadmin.msc), a graphical user interface (GUI) snap-in that is available on the Administrative Tools menu You can use the Windows Server Backup GUI to perform critical-volumes backups and full server backups. Note You can perform a system state backup only by using the Wbadmin.exe command-line tool. • Command-line Tools, which is required to install the Wbadmin.exe command-line tool for Windows Server Backup. “Command-line Tools” refers to a set of Windows PowerShell tools. 207

When you select Command-line Tools, you are prompted to install the required Windows PowerShell feature. You can use the Windows Server Backup command-line tool, Wbadmin.exe, to perform all types of backup, including system state backup. You can use the Windows Server Backup snap-in to back up entire volumes only, as follows: those volumes that contain system state files (critical-volumes backup) or all volumes (full server backup). The Windows Server Backup snap-in has two wizard options: a Backup Schedule Wizard and a Backup Once Wizard. To use one of the wizards for backing up critical volumes, you must know which volumes to select, or you can allow the wizard to select them when you specify that you want to enable system recovery. When you use the command-line tool for backing up critical volumes, the tool selects the correct volumes automatically. To back up system state, you must use the Wbadmin.exe command-line tool.

Windows Server backup types
In Windows Server 2008, you can use Windows Server Backup tools to back up three categories of domain controller data, all of which can be used to recover AD DS. Each backup type backs up a different set of data.

Contents of Windows Server backup types
The following list describes the backup types and the data that they contain: • System state, which includes all the files that are required to recover AD DS. System state includes at least the following data, plus additional data, depending on the server roles that are installed: • • • • • • • • • • Registry COM+ Class Registration database Boot files Active Directory Certificate Services (AD CS) database Active Directory database (Ntds.dit) file and log files SYSVOL directory Cluster service information Microsoft Internet Information Services (IIS) metadirectory System files that are under Windows Resource Protection

Critical volumes, which includes all volumes that contain system state files: • The volume that hosts the boot files, which consist of the Bootmgr file and the Boot Configuration Data (BCD) store • • The volume that hosts the Windows operating system and the registry The volume that hosts the SYSVOL tree 208

• •

The volume that hosts the Active Directory database The volume that hosts the Active Directory database log files

• Full server, which includes all volumes on the server, including Universal Serial Bus (USB) drives. The backup does not include the volume where the backup is stored.

Criteria for using backup types
The following table shows the qualities and restrictions that apply to each backup type. Use this table to determine the backup type to use.
Feature System state backup Critical-volumes backup Full server backup

Can be used to recover from registry or directory service configuration errors (recover AD DS)

Yes

Yes

Yes

Can be used for full server No (bare-metal) recovery with Windows Recovery Environment (Windows RE) Can be used to recover from unbootable conditions Can be used to recover specific files and folders Can be created by using Windows Server Backup snap-in (GUI) Can be created by using Wbadmin.exe command line tool Has incremental backup support Can be stored on a DVD or on a network share if the backup is performed manually (is not a scheduled backup) Can use any of the No

Yes

Yes

Yes

Yes

No No

Yes Yes

Yes Yes

Yes

Yes

Yes

No* No

Yes Yes

? Yes**

Yes***

No

No 209

Feature

System state backup

Critical-volumes backup

Full server backup

volumes that are included in the backup as the target volume Can be scheduled by No using the Windows Server Backup snap-in Yes Yes

* Each consecutive backup requires as much space as the first. To help manage the number of versions of system state backups that you store, you can use the wbadmin delete systemstatebackup command to remove old versions. For more information, see Wbadmin delete systemstatebackup (http://go.microsoft.com/fwlink/?LinkId=111836). ** Must be stored on a different hard disk from the source volumes, including external disks or DVDs. External storage devices must be connected to the backup computer. *** No, by default, but you can override the default by making a change in the registry. To store the system state backup on a volume that is included in the backup, you must add the AllowSSBToAnyVolume registry entry to the server that you are backing up. However, there are some known issues with storing system state backup on a volume that is included in the backup. For more information, see Known Issues for Backing Up Active Directory Domain Services.

Backup guidelines
The following guidelines for backup include the performance of backups to ensure redundancy of Active Directory data: • Create daily backups of all unique data, including all domain directory partitions on global catalog servers. • Create daily backups of critical volumes on at least two unique domain controllers, if possible. When you have environments with single-domain-controller forests, single-domaincontroller domains, or empty root domains, take special care to back up more often. • Ensure that backups are available in sites where they are needed. Do not rely on copying a backup from a different site, which is very time consuming and can significantly delay recovery. • Where domains exist in only one site, store additional backup files offsite in a secure location so that no backup file of a unique domain exists in only one physical site at any point in time. This precaution provides an extra level of redundancy in case of physical disaster or theft. • Make sure that your backups are stored in a secure location at all times. • Back up volumes that store Domain Name System (DNS) zones that are not Active Directory–integrated. You must be aware of the location of DNS zones and back up DNS servers accordingly. If you use Active Directory–integrated DNS, DNS zone data is captured as part of system state and critical-volume backups on domain controllers that are also DNS servers. 210

If you do not use Active Directory–integrated DNS, you must back up the zone volumes 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. Therefore, system state or critical-volume 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 directory partitions in your forest, make sure that you make a backup of the domain controllers that replicate those application directory partitions. • Create additional backups of domains in every geographic location where: • Large populations of users exist. • Critical populations of users exist, such as those who support company executives or operate critical business units. • • 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 installation media from a site where a backup exists to a site that has no backup for the purpose of performing an installation from media (IFM). Note You can use a system state or critical-volumes backup 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 restored backup media. You cannot use a system state or critical-volumes backup to restore a different domain controller or to restore a domain controller onto different hardware. You can only use a full server backup to restore a domain controller onto different hardware.

Scheduling regular backups
You can use the Backup Schedule Wizard to schedule regular, automatic critical-volumes or full server backups of your domain controllers. You need a current, verified, and reliable backup to: • Restore Active Directory data that becomes lost. • Recover a domain controller that cannot start up or operate normally because of software failure, hardware failure, or administrative error. For example, an administrator might have set overly restrictive permissions, either explicitly or by using a security policy, that deny the operating system access to the Ntds.dit file and log files. • Install AD DS from installation media that you create by using the ntdsutil ifm command. For information about installing a domain controller from installation media, see Installing an Additional Domain Controller by Using IFM. 211



Perform a forest recovery if forest-wide failure occurs.

For information about scheduling backups of AD DS in Windows Server 2008, see Scheduling Regular Full Server Backups of a Domain Controller (http://go.microsoft.com/fwlink/? LinkId=118008).

Immediate (unscheduled) backup
In addition to scheduling regular backups, perform an immediate backup when certain events occur in your environment. You can use the Backup Once Wizard or the command line to back up AD DS when the following conditions arise: • You have moved the Active Directory database, log files, or both to a different location on a disk. • • • • The operating system on a domain controller is upgraded. A Service Pack is installed on a domain controller. 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 by changing the value in the tombstoneLifetime attribute of the object CN=Directory Service,CN=Windows NT,CN=Services,CN-Configuration,DC=ForestRootDomain. The tombstone lifetime value in an Active Directory forest defines the number of days that a domain controller preserves information about deleted objects. For this reason, this value also defines the useful life of a backup that you use for disaster recovery or installation from backup media.

Backup frequency
The frequency of your backups depends on criteria that vary for individual Active Directory environments. In most Active Directory environments, users, computers, and administrators make daily changes to directory objects, such as group membership or Group Policy. 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 and domain client computers. 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 external record of these changes exists except in AD DS. Therefore, the more frequently you back up domain controllers, the fewer problems you will encounter if you need to restore this type of information. 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 made. To avoid re-creating accounts and potentially performing large numbers of manual

212

password resets, ensure that recent system state backups are always available to recover recent Create, Modify, and Delete operations.

Backup frequency criteria
Use the following criteria to assess the frequency of your backups: • Small environments with a single domain controller in the forest or domains that exist in a single physical location (that is, domains 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, domains 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 lose the objects that were created or modified since the last backup, the loss would not create a disruption of your operations. Major changes to the environment should always be immediately followed by a new system state backup. Note We always recommend that you have at least two domain controllers in each domain of your Active Directory forest.

Backup latency interval
After you perform an initial Active Directory backup on a domain controller, Event ID 2089 provides warnings about 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, and it continues daily until a backup of the partition occurs. This event serves as a warning to administrators and monitoring applications to make sure that domain controllers are backed up well before the tombstone lifetime expires. By monitoring this event, you can ensure that backups occur with sufficient frequency. Sufficient frequency is determined by the backup latency interval. The value for the backup latency interval is stored as a REG_DWORD value in the Backup Latency Threshold (days) registry 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. In a Windows Server 2008 forest, half the tombstone lifetime is 90 days. However, we recommend that you make backups at a much higher frequency than the default value of Backup Latency Threshold (days). By setting a minimum backup frequency, changing this setting to reflect that frequency, and monitoring Event ID 2089, you ensure the backup frequency that is established in your organization.

213

To set a different Backup Latency Threshold (days) value, use Registry Editor (Regedit.exe) to create the entry as a REG_DWORD and provide the appropriate number of days. More information about the Windows Server Backup tools and backing up AD DS is available in the Step-by-Step Guide for Windows Server 2008 AD DS Backup and Recovery (http://go.microsoft.com/fwlink/?LinkId=93077), as follows: • What’s New in AD DS Backup and Recovery? (http://go.microsoft.com/fwlink/? LinkId=118011) • Known Issues for AD DS Backup and Recovery (http://go.microsoft.com/fwlink/? LinkID=117940) • Best Practices for AD DS Backup and Recovery (http://go.microsoft.com/fwlink/? LinkId=118012) • General Requirements for Backup Up and Recovering AD DS (http://go.microsoft.com/fwlink/?LinkId=118013) • Scenario Overviews for Backing Up and Recovering AD DS (http://go.microsoft.com/fwlink/?LinkId=118014) Task requirements Before you back up a domain controller, see Performing an Unscheduled Backup of a Domain Controller (http://go.microsoft.com/fwlink/?LinkId=118015). The following tools, media, and credentials are required to perform the procedures for this task: • Windows Server Backup: • • • • • • Windows Server Backup snap-in (Wbadmin.msc) Windows Server Backup command-line tool (Wbadmin.exe) Internal or external hard disk drive Shared network folder Writable DVD

Backup media, as follows:

• Builtin Administrator credentials to schedule backups, or Backup Operator credentials to perform unscheduled backups To complete this task, you can perform the procedures in the following topics, depending on your backup needs: • Perform a Backup of Critical Volumes of a Domain Controller by Using the GUI (Windows Server Backup) • Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) • Perform a Full Server Backup of a Domain Controller by Using the GUI (Windows Server Backup) • Perform a Full Server Backup of a Domain Controller by Using the Command Line (Wbadmin)

214

Known Issues for Backing Up Active Directory Domain Services
The following known issues exist for backing up Active Directory Domain Services (AD DS) in Windows Server 2008: • Administrator credentials are required for scheduling backups. A member of Backup Operators cannot schedule backups by default, and the privilege cannot be delegated. • Windows Server Backup tools are not installed automatically. You must use Server Manager to install the Windows Server Backup Features, which include the Windows Server Backup snap-in (Wbadmin.msc) and the Wbadmin.exe component of Windows PowerShell command-line tools. • • Windows Server Backup does not support backing up to tape media. You cannot back up individual files and folders.

• You cannot perform or schedule system state backups by using Windows Server Backup. You must use the Wbadmin.exe command-line tool. • You cannot schedule weekly or monthly backups by using Windows Server Backup. However, you can use Task Scheduler to schedule manual backups that are performed at different times of the week. • A system state backup and recovery includes Active Directory–integrated Domain Name System (DNS) zones but does not include file-based DNS zones. To back up and restore filebased DNS zones, you have to back up and recover the entire volume that hosts the files. • The target volume for a system state backup cannot be a source volume by default. A source volume is any volume that has a file that is included in the backup. Therefore, the target volume cannot be any volume that hosts the operating system, Ntds.dit file, Ntds log files, or SYSVOL directory. To change this restriction, you can add the AllowSSBToAnyVolume registry entry to the server. However, there are known issues with storing a system state backup on a source volume: • Backups can fail. The backup can be modified during the backup process, which might cause the backup to fail. • Use of target space is inefficient. Twice the amount of space is necessary for a backup than for the original data. The volume must allocate twice the amount of space for the shadow copy process. The path for adding the new registry entry is as follows: HKLM\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\AllowSS BToAnyVolume Type: DWORD A value of 0 prevents the storing of system state backup on a source volume. A value of 1 allows the storing of system state backup on a source volume.

215

Perform a Backup of Critical Volumes of a Domain Controller by Using the GUI (Windows Server Backup)
You can use this procedure to back up critical volumes for a domain controller by using Windows Server Backup. You can also back up critical volumes by using the wbadmin start backup command with the -allCritical parameter. For more information, see Wbadmin start backup (http://go.microsoft.com/fwlink/?LinkId=111838). Note Windows Server Backup appears on the Administrative Tools menu by default, even if the Windows Server Backup feature is not installed. If Windows Server Backup is not installed, when you open Windows Server Backup, a message appears, saying that the tool is not installed and providing the instructions for installing Windows Server Backup. For more information about installing Windows Server Backup, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkID=96495). Membership in Builtin Administrators or Backup Operators, or equivalent, is the minimum required to complete this procedure. In addition, you must have write access to the target backup location. To perform a critical-volume backup for a domain controller 1. Click Start, point to Administrative Tools, and then click Windows Server Backup. 2. If you are prompted, in the User Account Control dialog box, provide Backup Operator credentials, and then click OK. 3. On the Action menu, click Backup once. 4. In the Backup Once Wizard, on the Backup options page, click Different options, and then click Next. 5. If you are creating the first backup of the domain controller, click Next to select Different options. 6. On the Select backup configuration page, click Custom, and then click Next. 7. On the Select backup items page, select the volumes to include in the backup. If you select the Enable system recovery check box, all critical volumes are selected. As an alternative, you can clear that check box, select the individual volumes that you want to include, and then click Next. Your selection must include the volumes that store the operating system, Ntds.dit, and SYSVOL. Note If you select a volume that hosts an operating system, all volumes that store system components are also selected. 216

8. On the Specify destination type page, click Local drives or Remote shared folder, and then click Next. 9. Choose the backup location as follows: • If you are backing up to a local drive, on the Select backup location page, in Backup destination, select a drive, and then click Next. • If you are backing up to a remote shared folder, do the following: a. Type the path to the shared folder. b. Under Access Control, select Do not inherit or Inherit to determine access to the backup, and then click Next. c. In the Provide user credentials for Backup dialog box, provide the user name and password for a user who has write access to the shared folder, and then click OK. 10. On the Specify advanced option page, select VSS copy backup and then click Next, 11. On the Summary page, review your selections, and then click Backup. 12. After the Backup Once Wizard begins the backup, click Close at any time. The backup runs in the background and you can view backup progress at any time during the backup. The wizard closes automatically when the backup is complete.

Additional considerations
The target volume for a critical-volume backup can be a local drive, but it cannot be any of the volumes that are included in the backup.

Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin)
You can use this procedure to back up system state on a domain controller. Membership in Builtin Administrators or Backup Operators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. In addition, you must have write access to the target backup location. To perform a system state backup of a domain controller 1. Click Start, click Command Prompt, and then click Run as administrator. 2. If you are prompted, in the User Account Control dialog box, provide Backup Operator credentials, and then click OK. 3. At the command prompt, type the following command, and then press ENTER:
wbadmin start systemstatebackup -backuptarget:<targetDrive>: -quiet

217

Where <targetDrive> identifies the local volume or the letter of the physical disk drive to receive the backup. You cannot store a system state backup on a network shared drive. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the backup operation.

Additional considerations
Be aware of the following issues when you perform a system state backup: • To use Wbadmin.exe, you must install Windows Server Backup. For more information about installing Windows Server Backup, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkID=96495). • The target volume for a system state backup can be a local drive, but it cannot be any of the volumes that are included in the backup by default. To store the system state backup on a volume that is included in the backup, you must add the AllowSSBToAnyVolume registry entry to the server that you are backing up. There are also some prerequisites for storing system state backup on a volume that is included in the backup. For more information, see Known Issues for AD DS Backup and Recovery (http://go.microsoft.com/fwlink/? LinkID=117940).

Perform a Full Server Backup of a Domain Controller by Using the GUI (Windows Server Backup)
A full server backup captures all volumes on all locally attached volumes. Windows Server Backup treats Universal Serial Bus (USB) drives and Internet SCSI (iSCSI) devices as locally attached volumes. If the backup destination is a locally attached drive, it is excluded from the backup set. You can use this procedure to back up all the volumes on a domain controller by using the Windows Server Backup snap-in. Note Windows Server Backup appears on the Administrative Tools menu by default, even if the Windows Server Backup feature is not installed. If Windows Server Backup is not installed, when you open Windows Server Backup, a message appears, saying that the tool is not installed and providing the instructions for installing Windows Server Backup. For more information about installing Windows Server Backup, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkID=96495). Membership in Builtin Administrators or Backup Operators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. In addition, you must have write access to the target backup location.

218

To perform an unscheduled full server backup of all volumes by using the graphical user interface (GUI) 1. Click Start, point to Administrative Tools, and then click Windows Server Backup. 2. If you are prompted, in the User Account Control dialog box, provide Backup Operator credentials, and then click OK. 3. On the Action menu, click Backup once. 4. In the Backup Once Wizard, on the Backup options page, click Different options, as shown in the following figure, and then click Next.

5. If you are creating the first backup of the domain controller, click Next to select Different options. 6. On the Select backup configuration page, click Full server, as shown in the following figure, and then click Next.

219

7. On the Specify destination type page, click Local drives or Remote shared folder, and then click Next. 8. Choose the backup location as follows: • If you are backing up to a local drive, on the Select backup location page, in Backup destination, select a drive, and then click Next.

220

• If you are backing up to a remote shared folder, on the Specify remote folder page, provide shared folder information, as shown in the following figure:

221

a. Type the path to the shared folder. b. Under Access Control, select Do not inherit or Inherit to determine access to the backup, and then click Next. c. In the Provide user credentials for Backup dialog box, provide the user name and password for a user who has write access to the shared folder, and then click OK. 9. On the Specify advanced option page, select VSS copy backup (recommended) and then click Next. 10. On the Confirmation page, review your selections, and then click Backup. 11. After the Backup Once Wizard begins the backup, click Close at any time. The backup runs in the background and you can view backup progress at any time during the backup. The wizard closes automatically when the backup is complete.

Additional considerations
The target volume for an unscheduled backup can be a local drive, but it cannot be any of the volumes that are included in the backup.

222

Perform a Full Server Backup of a Domain Controller by Using the Command Line (Wbadmin)
A full server backup captures all volumes on all locally attached volumes. Windows Server Backup treats Universal Serial Bus (USB) drives and Internet SCSI (iSCSI) devices as locally attached volumes. If the backup target is a locally attached drive, it is excluded from the backup set. You can use this procedure to back up all volumes with the Wbadmin.exe command-line tool. Membership in Builtin Administrators or Backup Operators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. In addition, you must have write access to the target backup location. To perform an unscheduled backup of all volumes by using the command line 1. Click Start, click Command Prompt, and then click Run as administrator. 2. If you are prompted, in the User Account Control dialog box, provide Backup Operator credentials, and then click OK. 3. At the command prompt, type the following command, and then press ENTER:
wbadmin start backup -include:<sourceDrive_1>:,<sourceDrive_2>:,... <sourceDrive_n>: -backuptarget:<targetDrive>: -quiet

Where: • <sourceDrive_x> identifies the volume or volumes to be backed up, separated by commas and no spaces. • <targetDrive> identifies the local volume or the letter of the network shared drive or physical disk drive to receive the backup. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the restore process.

Additional considerations
Be aware of the following issues when you perform unscheduled backups: • To use Wbadmin.exe, you must install Windows Server Backup. For more information about installing Windows Server Backup, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkID=96495). • The target volume for an unscheduled backup can be a local drive, but it cannot be any of the volumes that are included in the backup.

223

Recovering Active Directory Domain Services
You can use the information in this section to recover Active Directory Domain Services (AD DS) when directory services are disrupted as a result of problems with hardware, software, the network environment, or human error. To guard against damage from these types of disruptions, make sure that you are always prepared to restore AD DS with a timely backup of the volumes and servers that are critical to successful operation of your forest. When recovery of AD DS by restoration from a backup is necessary, the most common cause is either administrative error or hardware failure. The best defense against these problems is prevention. Be sure to take steps to protect Active Directory data from accidental deletion. You can also manage hardware replacement in a timely fashion, before it leads to failure and loss of Active Directory data.

Causes of disruptions
Disruptions to directory services can be caused by many conditions on a domain controller, in a domain or forest, and with service clients and applications that use AD DS. The following are some of the conditions that can disrupt directory services: • Reordering or changes to drive letters that cause the operating system, the directory service file, and logs to be unavailable in their expected locations • Excessive permissions on objects in AD DS, the file system, or the registry, or explicitly defined and assigned in Group Policy • Disk failure, which prevents access to or causes damage to the following sets of files: operating system, directory service and log, SYSVOL, and registry or other critical system files • Inability to restart AD DS in normal mode, for example, after an unscheduled power outage or software update • Antivirus utilities and other utilities, such as disk optimization utilities, which prevent unfettered access to the directory service file and logs • Inability of a domain controller to respond to Lightweight Directory Access Protocol (LDAP) requests, logon requests, or replication requests • Inability to boot from AD DS, for example, after an unscheduled power outage or software update • • • • • Physical site disaster, such as natural disasters or virus attacks or other security attacks Accidental deletions in AD DS, the file system, or the registry Rollback to a known good point in time Corruption that is localized to a domain controller Corruption that has replicated (the worst-case scenario)

224

Keys to protecting against disruptions
The keys to protecting your network from disruptions are preparation and prevention. To make sure that you are always able to recover from disruption, prepare by scheduling backups as follows: • Back up the volumes that are required to recover AD DS and the entire domain controller. • Back up all critical domain controllers, as described in Backing Up Active Directory Domain Services. • Back up on a daily schedule and when significant changes are made to the registry or the directory. Before you introduce configuration changes on domain controllers in production, test your configuration changes in a lab or on a test computer that mirrors the production environment in the same way that you test hardware configuration, service pack and software update revisions, performance load, and so on. Some configuration changes have immediate implications; some are apparent when a single event or operation occurs (such as a reboot or service startup); and some have chained implications (for example, if X and Y both occur, then Z occurs). Other changes have time-based or threshold-based implications. Be sure that you are aware of all the effects of a configuration change before you implement it in production. For more information about backup recommendations, see Backing Up Active Directory Domain Services. The most common causes of directory service disruption requiring recovery are administrative error and hardware failure. The best defense against these problems is prevention. You can prevent disruptions by taking steps to protect against easily avoidable problems: • Use the Protect object from accidental deletion option in Windows Server 2008 to prevent inadvertent deletions of critical data. For more information, see “Preventing unwanted deletions” in this topic. • • Monitor all critical services. Manage hardware replacement in a timely fashion.

When you consider recovery options, the objective is to use the fastest method that results in the least intrusive and most complete recovery. Options for recovery can range from repair of individual elements to restoration of a single domain controller. In the worst-case scenario, the only option might be to recover all domain controllers in a domain or forest.

Preventing unwanted deletions
Most large-scale deletions are accidental. In many cases, you may have to perform a recovery operation to recover objects that have been deleted from AD DS. In Windows Server 2008, the Active Directory Users and Computers snap-in provides the Protect object from accidental deletion option. When enabled, Protect object from accidental deletion implements the Deny delete subtree permission. This option is available in Active Directory Users and Computers on the domain controller and when viewed through Remote Server Administration Tools (RSAT) on computers running Windows Server 2008 and Windows Vista. When you enable 225

Advanced Features on the View menu, the Protect object from accidental deletion option is available on the Object tab. You can open the Properties page for each container in the domain and enable this option. Note CN=Users,DC=DomainName and CN=Computers,DC=DomainName are protected from deletion by system flags on the objects. Use this option to protect all other containers up to the domain level. Good candidates for protection are containers that store Group Policy objects (GPOs) and Active Directory–integrated Domain Name System (DNS) zones. When you enable the Protect object from accidental deletion option, neither the container nor any child object can be deleted by any administrator or other user. An administrator with the right to log on locally to a domain controller and the right to open Active Directory Users and Computers can enable or disable the setting. Pay particular attention to protecting organizational units (OUs) that might have been created in an earlier version of Windows. When you create an OU by using Active Directory Users and Computers in Windows Server 2008, the Protect container from accidental deletion check box is selected by default. On domain controllers that are running earlier versions of Windows, you must apply the Deny access control entries (ACEs) permission on the Security tab of the properties page of the containers to implement protection from accidental deletion. For information about how to apply these access control entries (ACEs) manually, see Guarding Against Accidental Bulk Deletions in Active Directory (http://go.microsoft.com/fwlink/?LinkId=116365).

Recovery solutions
When you are faced with unacceptable directory service conditions that cannot be resolved reliably by manual updates, your recovery solutions depend on data issues, hardware issues, time constraints, and the backups that are available.

Solutions for configuration errors—nonauthoritative restore
To undo errors in configuration so that AD DS returns to a previous healthy state and is then brought up to date through replication, perform a nonauthoritative restore from backup. This process overwrites the current version of AD DS with the version in the backup. After replication, the directory is current with the rest of the domain. You can restore AD DS by using a system state backup, a critical-volumes backup, or a full server backup. If a system state backup is available, use the system state backup to recover from registry or directory service configuration errors. You can use a critical-volumes backup as well, but it contains more than Active Directory data and it is not required for restoring AD DS only. Use fullserver recovery for more serious problems, as described in “Solutions for hardware failure or file corruption” later in this topic.

226

Note Nonauthoritative restore from backup requires that the domain controller is running in Directory Services Restore Mode (DSRM). You cannot perform this procedure by stopping AD DS.

Solutions for data loss—authoritative restore
Accidental deletions can occur in any writable directory partition. Such deletions are most common in the domain directory partition, but they can also occur in the configuration directory partition. Objects in the schema directory partition are protected against deletion. The method for recovering deleted objects is authoritative restore. If you have data loss and you can identify the source and quantity of the loss, you can recover the lost data by performing an authoritative restore. If you lose domain data, you must perform recovery by restoring a domain controller that hosts a writable copy of the domain directory partition where the data loss occurred. If objects are deleted from the configuration directory partition, you can recover these objects by restoring any domain controller in the forest. There are special considerations if the deleted objects have a forward link-back link relationship with each other. This relationship exists for security groups and distribution groups. Restoring group memberships Security principals are objects that can have group memberships. Recovering deleted security principals requires not only restoring the object itself but also restoring the group memberships of each restored security principal. You use files that are generated by Ntdsutil during authoritative restore to recover group memberships. Group membership is defined by linked attributes on the group object and on the group member object: the member attribute of the group object is a forward link attribute that links to the memberOf attribute (the back link) of the group member, which can be a user, a computer, or another group. If you perform the restore on a domain controller that is not a global catalog server, only group memberships for groups that are stored in the domain are restored. If you perform the restore on a global catalog server, group memberships in universal groups that are stored in other domains in the forest are also restored. However, restoring memberships in domain local groups that are stored in other domains requires additional steps that involve using the files that Ntdsutil generates during authoritative restore. When you authoritatively restore security principals on a domain controller that is running a version of Windows Server later than Windows Server 2003 (that is, Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008), the Ntdsutil command-line tool recovers group memberships automatically (restores the memberOf value on the restored security principal object) for all groups that were created or updated at a forest functional level of at least either Windows Server 2003 or Windows Server 2003 interim. However, replication order can undo the restored memberships in the recovery domain. For this reason, it is best to perform the additional steps to recover group memberships in the recovery domain as well. For more information about restoring group memberships, see Performing Authoritative Restore of Active Directory Objects. Methods of authoritative restore 227

Depending on replication conditions in the domain of the deletions, you can use the following methods to perform an authoritative restore: • Nonauthoritative restore from backup, followed by authoritative restore: Unless you can isolate a domain controller that has not received the deletions, authoritative restore must be preceded by a nonauthoritative restore from backup to restore the directory to a former state that contained the deleted objects. With the deleted objects restored, you can mark them as authoritative so that replication does not overwrite them with the delete condition that still exists on the other domain controllers in the domain. • Authoritative restore only: If you identify the data loss quickly and you can isolate a global catalog server in the domain where the deletion occurred that has not received replication of the deletions, you can mark the objects as authoritative on the global catalog server and avoid performing an initial restore from a backup (nonauthoritative restore). This option depends on your ability to stop inbound replication on the global catalog server before replication of the deletions is received. Global catalog servers often have longer replication latency than other domain controllers. Global catalog servers are preferred as recovery domain controllers because they store more group information. However, any latent domain controller in the domain of the deletions that has not received replication of the deletions can serve as the recovery domain controller if you want to avoid restoring from backup. For more information about performing authoritative restore without restoring from backup, see Performing Authoritative Restore of Active Directory Objects.

Recovery options with no available backup
If you have data loss but you do not have a backup, you must recreate the deleted objects. As an alternative, where data loss is minimal, you might be able to recover lost data by using the undelete capability that recovers objects by reanimating the object tombstone (the retained record of the object deletion). The Windows Server 2003 and Windows Server 2008 directory database supports an LDAP application programming interface (API) that reanimates the tombstone of a single object (that is, it “undeletes” the object). This API is available for developing applications to restore the attributes that are preserved on tombstones, which include the object security identifier (SID), globally unique identifier (GUID), and security descriptor, as well as any indexed attributes. On domain controllers that are running Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server R2, or Windows Server 2008, the sIDHistory attribute is also retained. All other attributes must be recreated. In the case of a deleted user object, you must repopulate attributes to re-establish group memberships, profile path, home directory, and contact information. You must also reset passwords and communicate the password to the users so they can log on to the domain. For information about reanimating tombstones, see Reanimating Active Directory Tombstone Objects (http://go.microsoft.com/fwlink/?LinkId=116204).

Solutions for hardware failure or file corruption
If you have hardware issues that require the replacement of the hard drive on a domain controller, you must either recover the full server to the new hardware or reinstall the operating system. If you 228

have widespread corruption in the file system, your best solution is also full server recovery or reinstallation. To decide whether or not to perform a full server recovery, consider the following conditions: • A full server recovery reformats and repartitions all disks that are attached to the server. • A full server recovery might be more time consuming than reinstalling the operating system. • Reinstallation requires a cleanup of server metadata on the failed domain controller. • Reinstallation results in data loss. All servers have roles and features installed. Each role has configuration state in AD DS, the file system, and the registry, and a role frequently has its own data store. For example, the server might be configured for DNS, Dynamic Host Configuration Protocol (DHCP), Windows Internet Name Service (WINS), administration tools, and registry settings for maximum transmission unit (MTU), maxPacketSize, and security. If you have to reinstall, you must either export and import all these settings or recreate them. This method is certain to be time consuming and error prone. Reinstalling and restoring criteria In general, use the following criteria to the decide whether to reinstall or restore a domain controller from backup: • Reinstall the operating system under the following conditions: • You do not have an available backup. • You must have the domain controller back online as soon as possible and reinstallation is faster than restoring. • You have exhausted all known avenues of troubleshooting a fault or error condition, and continued troubleshooting is not likely to succeed or will result in diminishing returns with more time spent. • Perform a full server restore of the domain controller under the following conditions: • • Reinstalling will result in an unacceptable loss of data. You want to recover from localized or replicated corruption.

• The domain controller is running other server services, such as Exchange, or it contains other data that you must restore from a backup. Restoring AD DS after reinstalling the operating system If you reinstall the operating system, you can restore AD DS in one of the following ways: • Use Dcpromo to reinstall AD DS and allow replication from another, healthy domain controller in the domain to update the domain controller. • Restore AD DS from backup (nonauthoritative restore). Then, allow replication from another, healthy domain controller in the domain to update the domain controller. This method requires less replication than reinstalling AD DS. • Install AD DS from installation media. This method, called install from media (IFM), requires that you have created installation media that can be used to install AD DS. You use Ntdsutil to create the media on a healthy domain controller in the domain. In this case, recovery is faster

229

because Active Directory replication is not required. For more information about installing from media, see Installing an Additional Domain Controller by Using IFM.

Recovery tasks
This section includes the following tasks for recovering AD DS: Performing Nonauthoritative Restore of Active Directory Domain Services Performing Authoritative Restore of Active Directory Objects Performing Authoritative Restore of an Application Directory Partition Performing a Full Server Recovery of a Domain Controller Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup Restoring a Domain Controller Through Reinstallation

Performing Nonauthoritative Restore of Active Directory Domain Services
A nonauthoritative restore is the method for restoring Active Directory Domain Services (AD DS) from a system state, critical-volumes, or full server backup. 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 AD DS from backup, the domain controller queries its replication partners. Replication partners use the standard replication protocols to update AD DS and associated information, including the SYSVOL shared folder, on the restored domain controller. You can use a nonauthoritative restore to restore the directory service 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 reinstate a domain controller, often after catastrophic or debilitating hardware failures. In the case of data corruption, do not use nonauthoritative restore unless you have confirmed that the problem is with AD DS. Note If your objective is to recover objects that were deleted since the last backup, first perform a nonauthoritative restore from backup to reinstate the deleted objects and then perform an authoritative restore to mark the deleted objects as authoritative so that they are not overwritten during replication. When you are performing both a nonauthoritative restore and an authoritative restore, do not allow the domain controller to restart after the nonauthoritative restore. For information about performing authoritative restore, see Performing Authoritative Restore of Active Directory Objects.

230

Nonauthoritative Restore Requirements
You can perform a nonauthoritative restore from backup on a Windows Server 2008 system that is a stand-alone server, member server, or domain controller. On domain controllers that are running Windows Server 2008, you can stop and restart AD DS as a service. Therefore, in Windows Server 2008, performing offline defragmentation and other database management tasks does not require restarting the domain controller in Directory Services Restore Mode (DSRM). However, you cannot perform a nonauthoritative restore after simply stopping the AD DS service in regular startup mode. You must be able to start the domain controller in Directory Services Restore Mode (DSRM). If the domain controller cannot be started in DSRM, you must first reinstall the operating system. If you need to reinstall the operating system and then restore AD DS, see Restoring a Domain Controller Through Reinstallation or Restoring a Domain Controller Through Reinstallation. To perform a nonauthoritative restore, you need one of the following types of backup for your backup source: • System state backup: Use this type of backup to restore AD DS. If you have reinstalled the operating system, you must use a critical-volumes or full server backup. If you are restoring a system state backup, use the wbadmin start systemstaterecovery command. • Critical-volumes backup: A critical-volumes backup includes all data on all volumes that contain operating system and registry files, boot files, SYSVOL files, or Active Directory files. Use this type of backup if you want to restore more than the system state. To restore a criticalvolumes backup, use the wbadmin start recovery command. • Full server backup: Use this type of backup only if you cannot start the server or you do not have a system state or critical-volumes backup. A full server backup is generally larger than a critical-volumes backup. Restoring a full server backup not only rolls back data in AD DS to the time of backup, but it also rolls back all data in all other volumes. Rolling back this additional data is not necessary to achieve nonauthoritative restore of AD DS. For information about performing a full server backup for disaster recovery, see Performing a Full Server Recovery of a Domain Controller on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=116206).

SYSVOL restore
SYSVOL is always restored nonauthoritatively during a restore of AD DS. Restoring SYSVOL requires no additional procedures. If you deleted file system policy and have a backup of policy that you created by using Group Policy Management Console, you can recover the policy by using that tool. For information about managing Group Policy, see Group Policy Management Console (http://go.microsoft.com/fwlink/?LinkId=101634). If you deleted the Default Domain Policy or Default Domain Controllers Policy, you can use Dcgpofix.exe to rebuild the policy. For information about using Dcgpofix.exe, see Dcgpofix.exe on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=109291). When you use System Recovery Options in Windows Server Backup to restore a Windows Server 2008 domain controller in an environment that has Distributed File System (DFS) 231

Replication implemented, the SYSVOL restore is performed nonauthoritatively by default. To perform an authoritative restore of SYSVOL, include the -authsysvol switch in your recovery command, as shown in the following example:
wbadmin start systemstaterecovery <otheroptions> -authsysvol

If you use File Replication Service (FRS), the restore operation sets the BURFLAGS registry entries for FRS, which affects all replica sets that are replicated by FRS. Task requirements The following tools are required to perform the procedures for this task: • • • Remote Desktop Connection (optional) Wbadmin.exe Bcdedit.exe

To complete this task, perform the following procedures: 1. Restart the domain controller in DSRM by using one of the following methods: Restart the Domain Controller in Directory Services Restore Mode Locally Or Restart the Domain Controller in Directory Services Restore Mode Remotely 2. Restore AD DS from Backup (Nonauthoritative Restore) 3. Verify AD DS restore

Additional references
• • • Performing 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 (DSRM) locally. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not as a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior 232

registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Stepby-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). You can restart a domain controller in DSRM manually by pressing the F8 key during domain controller startup, which requires watching the startup and waiting for the appropriate point in the startup to press the key. This method is tedious and can waste time if you miss the brief window of opportunity for selecting the restart mode. On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. When you are finished managing a domain controller in DSRM, if you have used System Configuration or Bcdedit.exe to restart the domain controller in DSRM, you must change the configuration so that the domain controller restarts in normal mode. Note A benefit of using System Configuration or Bcdedit.exe for implementing restart of a domain controller into DSRM is that normally the domain controller cannot be inadvertently restarted. This benefit is particularly useful when you are performing a nonauthoritative restore from backup followed by an authoritative restore. You can also use System Configuration or Bcdedit.exe to restart a domain controller in DSRM remotely. To use System Configuration or Bcdedit.exe and Remote Desktop Connection to restart a domain controller in DSRM remotely, see Restart the Domain Controller in Directory Services Restore Mode Remotely. Membership in the Domain Admins group is the minimum required complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM is required to log on to the domain controller in DSRM. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). 233

Restarting the domain controller in DSRM locally
You can use either of the following methods to restart the domain controller in DSRM: To restart a domain controller in DSRM locally by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click System Configuration. 2. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 3. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. 4. Perform procedures in DSRM. 5. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. To restart a domain controller in DSRM locally by using the command line 1. Click Start, click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

4. When you are still in DSRM and you are ready to restart in normal mode, open a command prompt and type the following, and then press ENTER:
bcdedit /deletevalue safeboot

5. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

Value

Description

/set safeboot dsrepair shutdown –t 0 -r /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting. 234

See Also
Restart the Domain Controller in Directory Services Restore Mode Remotely

Restart the Domain Controller in Directory Services Restore Mode Remotely
If you have remote access to a domain controller, you can restart the domain controller in Directory Services Restore Mode (DSRM) remotely. Remote access requires the user right to log on locally to a domain controller. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line or to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. To restart the domain controller in DSRM remotely, you first use Remote Desktop Connection to connect to the domain controller while it is in normal startup mode. Remote Desktop Connection must be enabled on the target domain controller. After the domain controller has restarted, you can use Remote Desktop Connection to reconnect to the domain controller and then log on as the local Administrator, using the DSRM password. You can use this procedure to connect to a domain controller remotely, restart it in DSRM, and then reconnect to it as the DSRM administrator. 235

Membership in Domain Admins, or equivalent, is the minimum required to complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM and the user right to log on locally to a domain controller are required to log on to the domain controller in DSRM. Members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the user right to log on locally to a domain controller by default. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. Using a domain administrative account to log on to an RODC can compromise the server. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). To restart a domain controller in DSRM remotely by using the Windows GUI 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. On the Start menu, point to Administrative Tools, and then click System Configuration. 3. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 4. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 5. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 6. The domain controller name should still be showing in Computer. If it is not, select it from the list, and then click Connect. 7. In the Windows Security dialog box, click Use another account. 8. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 9. In Password, type the DSRM password, and then click OK. 236

10. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 11. Type MachineName\Administrator, and then press ENTER. 12. Perform procedures in DSRM. 13. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. This procedure will disconnect your remote session. To restart a domain controller in DSRM remotely by using the command line 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. Open a command prompt. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 4. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 5. The domain controller name should still be showing in Computer. If it is not, select it in the list, and then click Connect. 6. In the Windows Security dialog box, click Use another account. 7. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller.

237

8. In Password, type the DSRM password, and then click OK. 9. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 10. Type MachineName\Administrator, and then press ENTER. 11. Perform procedures in DSRM. 12. When you have finished performing procedures in DSRM, restart the domain controller normally: a. In DSRM, open a command prompt, type the following command, and then press ENTER:
bcdedit /deletevalue safeboot

b. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 –r

The domain controller restarts normally. This procedure will disconnect your remote session.
Value Description

bcdedit /set safeboot dsrepair shutdown –t 0 -r bcdedit /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Enable Remote Desktop Create a Remote Desktop Connection Restart the Domain Controller in Directory Services Restore Mode Locally

Restore AD DS from Backup (Nonauthoritative Restore)
Nonauthoritative restore from backup restores Active Directory Domain Services (AD DS) from its current state to the previous state of a backup. Use this procedure before you perform an authoritative restore procedure to recover objects that were deleted after the time of the backup. To restore AD DS from backup, use a system state or critical-volumes backup. To restore AD DS from backup, you must restart the domain controller in Directory Services Restore Mode (DSRM).

238

Note If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). Be sure that you know the name and location of the version of the backup that you are restoring. Backup files are named for the date and time of the backup. When you restore the backup, the version must be stated in the form MM/DD/YYYY-HH:MM (month/day/year-hour:minute), which specifies the name of backup that you want to restore. The Wbadmin.exe command-line tool does not require that you provide the target for the recovery. By specifying the backup version that you want to recover, the command proceeds to recover to the source location of the backup version that you specify. Note The systemstaterecovery command in Wbadmin.exe causes a nonauthoritative restore of SYSVOL by default (only updates to SYSVOL since the time of the backup are replicated to the recovery domain controller). If you want to restore SYSVOL authoritatively (all of SYSVOL is replicated from the recovery domain controller to other domain controllers in the domain), specify the –authsysvol option in the command. The Administrator password for DSRM is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. The server must be running in DSRM. To perform a nonauthoritative restore of AD DS 1. At the Windows logon screen, click Switch User, and then click Other User. 2. Type .\administrator as the user name, type the DSRM password for the server, and then press ENTER. 3. Open a Command Prompt. 4. At the command prompt, type the following command, and then press ENTER:
wbadmin get versions -backuptarget:<targetDrive>: -machine:<BackupComputerName>

Where: •
<targetDrive>:

is the location of the backup that you want to restore.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was made. 5. Identify the backup version that you want to restore. You must enter this backup version exactly in the next step. 6. At the command prompt, type the following command, and then press ENTER:
wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM>

239

-backuptarget:<targetDrive>: -machine:<BackupComputerName> -quiet

Where: • •
<MM/DD/YYYY-HH:MM> <targetDrive>:

is the version of the backup that you want to restore.

is the volume that contains the backup.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was taken. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the restore process and then press Y to confirm that the replication engine for SYSVOL has not changed since you created the backup. After the recovery operation is complete, if you are not going to perform an authoritative restore of any restored objects, restart the server.

Additional references
• • • • • 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 Performing Authoritative Restore of Active Directory Objects

Verify AD DS restore
After you complete a restore of Active Directory Domain Services (AD DS), you can use this procedure to verify the restore. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify an Active Directory restorefrom backup 1. After the restore operation completes, restart the computer in Start Windows Normally mode. If you used Bcdedit.exe to configure startup in Directory Services Restore Mode (DSRM), see Restart the Domain Controller in Directory Services Restore Mode Remotely or Restart the Domain Controller in Directory Services Restore Mode Locally for information about changing the configuration back to normal startup mode. 2. After you are able to log on to the system, perform the following verification steps: At a command prompt, use the repadmin /showsig command to verify that the invocation ID has changed. The invocation ID is the directory database globally unique identifier 240

(GUID), which the Directory System Agent (DSA) uses to identify the version of the database. The invocation ID changes during the Active Directory restore process to ensure the consistency of the replication process. Verify that the previous entry appears in the retired signatures list. At a command prompt, use the repadmin /showrepl command to verify that there are no replication errors and all directory partitions are replicating properly with the required replication partners. You can determine the replication partners by selecting the NTDS Settings object for the restored server in Active Directory Sites and Services. At a command prompt, use the net share command to verify that the NETLOGON and SYSVOL shares appear. At a command prompt, use the dcdiag command to verify success of all tests on the domain controller. Use Active Directory Users and Computers to verify that the deleted objects that you wanted to recover from the backup are restored. If you have a Volume Shadow Copy Service (VSS) snapshot of the database, you can use the Active Directory database mounting tool (Dsamain.exe) to mount the database and view it through Active Directory Users and Computers to compare the objects. For information about the Active Directory database mounting tool, see the Step-by-Step Guide for Using the Active Directory Database Mounting Tool in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=103333).

Performing Authoritative Restore of Active Directory Objects
An authoritative restore process returns a designated, deleted Active Directory object or container of objects to its predeletion state at the time when it was backed up. For example, you might have to perform an authoritative restore if an administrator inadvertently deletes an organizational unit (OU) that contains a large number of users. In most cases, there are two parts to the authoritative restore process: a nonauthoritative restore from backup, followed by an authoritative restore of the deleted objects. If you perform a nonauthoritative restore from backup only, the deleted OU is not restored because the restored domain controller is updated after the restore process to the current status of its replication partners, which have deleted the OU. To recover the deleted OU, after you perform nonauthoritative restore from backup and before allowing replication to occur, you must perform an authoritative restore procedure. During the authoritative restore procedure, you mark the OU as authoritative and let the replication process restore it to all the other domain controllers in the domain. After an authoritative restore, you also restore group memberships, if necessary.

241

Note If you can isolate a domain controller in the domain that has not received replication of the deletion, the preliminary, nonauthoritative restore from backup is not necessary. For more information, see Recovering deletions without restoring from backup. You can restore objects in domain directory partitions, application directory partitions, and the configuration directory partition, as follows: • Domain directory partitions: You must restore the objects on a domain controller in the domain. • Application directory partitions: You must restore the objects on a domain controller that hosts the application directory partition. If you delete an entire application directory partition, you must restore the domain naming operations master to recover the application directory partition. • Configuration directory partitions: You can restore objects on any domain controller in the forest. Note You can also restore Group Policy objects (GPOs). For information about restoring GPOs, see “Back Up, Restore, Import, and Copy Group Policy Objects” in online Help for the Group Policy Management Console (GPMC). When an Active Directory object is marked for authoritative restore, its version number is changed so that the number is higher than the existing version number of the deleted object, which replicates as a tombstone in the Active Directory replication system. The change in version number ensures that any object that you restore authoritatively is replicated from the restored domain controller to other domain controllers in the forest, updating the tombstone object to the restored object. An authoritative restore is most commonly used to restore corrupt or deleted objects, often to recover unintentionally deleted user and group objects. 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 help optimize data consistency, integrity, and security.

Determining objects to restore
Before you perform an authoritative restore operation, determine the objects that must be restored. On domain controllers that are running Windows Server 2008, you can use Ntdsutil to take a snapshot of the directory database. A snapshot is a shadow copy—created by the Volume Shadow Copy Service (VSS)—of the volumes that contain the Active Directory database and log files. You can use the Active Directory database mounting tool (Dsamain.exe) to mount these database snapshots and view the directory data in a Lightweight Directory Access Protocol (LDAP) tool such as Active Directory Users and Computers, ADSI Edit, or Ldp. The database mounting tool can improve recovery processes by providing a means to compare data as it exists in snapshots or backups that are taken at different times so that you can better decide which data to restore after data loss. This eliminates the need to restore multiple backups to compare the Active Directory data 242

that they contain. When inadvertent deletions or modifications occur, you can use a snapshot to compare the data in the current directory against data in the snapshot. If you take regular snapshots, you can sometimes avoid having to restore AD DS if you can identify the differences in the data and return the affected objects to their correct state. When a recovery operation is required, you can use a database snapshot to assess the differences and determine the objects that you want to authoritatively restore. For information about using VSS shadow copies and the Active Directory database mounting tool, see the Step-by-Step Guide for Using the Active Directory Database Mounting Tool in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=103333).

Selecting objects to restore
When you are selecting objects that you want to replicate authoritatively, it is important to select the object that is lowest in the directory subtree as possible that you can still use to recover the deleted objects. In this way, you avoid reverting objects back in time that are not related to the deletion. Objects other than the deleted objects might have been modified after the backup was created. When you restore an OU, any changes that are made up to the time that a backup is restored are rolled back to their values at the time of the backup. For any user accounts, computer accounts, and security groups in the restored OU that were not among the deletions being restored, this rollback might mean the loss of the most recent changes to passwords, home directory, profile path, location and container information, group membership, and any security descriptors that are defined on those objects and attributes. For example, if an object with a password, such as a user or computer or trust account, is authoritatively restored, the password value of the restored object reverts to the password value at the time of the backup. In this case, user, computer, and service accounts that have a record of only the current password cannot log on because they have no record of the password that existed when the backup was created. In this way, group membership or other data can also be lost. Updates to the password are blocked because the restored value is authoritative during replication. To minimize the impact of rolling unrelated objects back in time, target as few objects as possible. If you have relatively few deletions to restore, you might be able to restore each object individually. If you have a relatively large number of deleted objects to restore, use the container object that contains most of the deleted objects. Ideally, the container that you restore will contain all the objects that you need to recover.

Selecting application directory partitions to restore
If you are restoring an application directory partition, the selection process is different from the process that you use to select other Active Directory objects. To authoritatively restore an application directory partition, follow the procedures that are provided for this task but use the procedure in Performing Authoritative Restore of an Application Directory Partition to mark the application directory partition as authoritative, and do not perform the procedures for restoring group memberships.

243

Restoring group memberships after authoritative restore
When a user object is deleted inadvertently, you 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. This condition is multiplied 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 you restore.

LVR and restoration of group memberships
Restoration of group memberships for security principals 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 linkedvalue replication (LVR). LVR is a feature that is available when the forest has a functional level of at least Windows Server 2003 interim or Windows Server 2003. In groups that are created before LVR is in effect, the member attribute of a group object 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 of a group object are replicated separately. In this case, group memberships are restored when you use the Ntdsutil command-line tool to authoritatively restore a user, group, or computer object. Important The memberOf attribute (or any back-link attribute) exists only because of its link to the member attribute (or any corresponding forward-link attribute). The back-link is generated only when it is accessed, and it is not replicated. Only the forward-link attribute value can be updated and replicated. 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. When you use the Ntdsutil command-line tool to authoritatively restore a subtree or a single object, the ability of Ntdsutil to automatically 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 (that is, after 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.

244

Note Although Ntdsutil restores back-links for LVR groups, replication order can result in the memberships being dropped. For more information, see Performing Authoritative Restore of Active Directory Objects.

Authoritative restore of pre-LVR group memberships and groups in different domains
The version of Ntdsutil that is included with Windows Server 2003 Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, and Windows Server 2008 provides the ability to also restore the memberships of groups that were created before LVR was implemented and in groups that can have members from other domains. Ntdsutil creates a text file that identifies the authoritatively restored objects. In addition, Ntdsutil creates an LDAP Data Interchange Format (LDIF) file (.ldf) that identifies restored objects that have back-links. You can use the .ldf file to regenerate memberOf back-links on restored security principal objects (users, groups, and computers) in a forest where LVR was not in effect when the groups that are identified in the memberOf back-links were created. To restore group memberships in groups that are stored in other domains (that is, for universal group or domain local group memberships), additional steps are required. Use the .txt file that Ntdsutil generates during authoritative restore to generate an .ldf file in each additional domain that has groups in which restored security principals have memberships. The updates to Ntdsutil that generate files that you can use to recover group memberships for preLVR groups and groups in other domains were introduced in Windows Server 2003 with SP1. The steps that you perform are different if you are restoring the objects on a domain controller that is running an earlier version of Windows Server. If you are performing authoritative restore in a pre– Windows Server 2003 SP1 environment, see “Procedures for Domain Controllers Running Windows Server 2003 with No Service Pack Installed” in Performing an Authoritative Restore of Active Directory Objects(http://go.microsoft.com/fwlink/?LinkId=68564).

Files for recovering group memberships following authoritative restore
When you perform authoritative restore, Ntdsutil creates the following files that are used to recover group memberships: • ar_YYYYMMDD-HHMMSS_links_Domain.ldf, which is an LDIF file that is generated for the domain in which you perform the authoritative restore procedure. This file contains back-link information for the restored objects. If you perform the procedure on a global catalog server, a separate .ldf file is created for each domain in the forest. You can use this file with the Ldifde.exe command-line tool to import the back-links to recover universal and global group memberships in environments that include pre-LVR groups. For environments that do not include pre-LVR groups, the Ntdsutil tool recovers group memberships automatically in the recovery domain and in the forest (for universal groups) if the recovery domain controller is a global catalog server. If the restore includes security principals that can have memberships in domain local groups in other domains, you use the ar_YYYYMMDD-HHMMSS_objects.txt text 245

file that is generated during authoritative restore to create an .ldf file to restore the memberships in each additional domain. • ar_YYYYMMDD-HHMMSS_objects.txt, which is a text file that contains a list of the authoritatively restored objects. This file is generated for each individual object or container that you mark as authoritative. You can use this file to generate an .ldf file that you can use to recover memberships in domain local groups and universal groups (if you are not restoring a global catalog server) in other domains. This file is created on any domain controller that you authoritatively restore. Global catalog servers do not store the member attribute of domain local groups. Therefore, even if you perform the restore on a global catalog server, you must always use this file to generate an .ldf file in any domain where there are domain local groups of which restored security principals might be members. You must create a separate .ldf file for each object or container that you mark as authoritative. Note Although group memberships are restored automatically when you use Ntdsutil to recover membership in LVR groups, it is best to process the .ldf files to ensure recovery. In some cases, replication order can result in lost memberships. For more information, see Known Issues for Authoritative Restore.

Using a global catalog server for authoritative restore
If possible, perform the authoritative restore on a global catalog server in the domain where the objects were deleted to recover security principals and group memberships. Global catalog servers store a single, writable domain and a partial, read-only replica of all other domains in the forest. A partial replica means that the global catalog stores all objects, but with a limited set of attributes on each object. Check the properties of the NTDS Settings object of the server object in Active Directory Sites and Services to determine that a domain controller is a global catalog server. Global catalog and group memberships In relation to the three types of security groups—global groups, domain local groups, and universal groups—global catalog servers are best suited for recovering group memberships after an authoritative restore procedure because they store memberships of all universal groups in the forest and all global groups in the domain. Security group memberships are restored on a global catalog server as follows: • Global groups: Security principals (users, groups, and computers) can be members of only the global groups that are created in the same domain. Global catalog servers store a writable domain directory partition. Therefore, they can restore global group memberships for the recovery domain. • Universal groups: Security principals can be members of universal groups that are created in any domain. However, the member attribute is among the attributes that are stored on the read-only universal group objects in the global catalog. Therefore, a global catalog server can recover universal group memberships for all domains in the forest. A domain 246

controller that is not a global catalog server stores only universal group objects that are created in its own domain. • Domain local groups: Security principals can be members of domain local groups that are created in any domain. Memberships in domain local groups in the recovery domain are restored automatically during authoritative restore. However, the global catalog does not store the member attribute for read-only domain local group objects. Therefore, for restored security principals that have memberships in domain local groups in other domains, you must recover these memberships by performing follow-up procedures in each additional domain.

Recovering deletions without restoring from backup
If you can isolate a global catalog server (or any domain controller, but preferably a global catalog server) in the domain where the deletion occurred before the server receives replication of the deletion, you might be able to avoid performing a preliminary restore from backup (nonauthoritative restore) and having to extend the restore process to other domains. Use the repadmin /showrepl command to determine the date and time of the latest inbound replication of the domain directory partition where the deletions occurred. Global catalog servers often have greater replication latency than ordinary domain controllers, and they are better restore candidates in general because they store universal group memberships. If you can stop inbound replication on a latent global catalog server, you can perform an authoritative restore on the global catalog server to recover the deleted memberships for all groups in the domain and for all universal groups in other domains. If you want to use a latent global catalog server for restoring deleted objects, you must take steps to stop inbound replication immediately. You can use one of the following methods to stop replication: • Use the Services snap-in to stop AD DS. In this case, other services continue to operate. • Take the global catalog service offline by restarting it in Directory Services Restore Mode (DSRM). In this case, all other directory-related services are stopped in addition to AD DS. • Use Repadmin.exe to stop inbound replication. In this case, the domain controller continues to operate but does not receive replication updates.

Retention (merge) of new group memberships or other attributes after authoritative restore
The authoritative restore procedure results in a merge of authoritatively restored objects and attributes and existing objects and attributes. For example, do not expect that users that have been added to a group (after the backup that is used to restore the deleted group) will be removed by an authoritative restore of the group object. Instead, new attributes of objects that are specified in the authoritative restore are preserved during replication. Therefore, authoritative restore does not remove group memberships that were added between the time of the backup that is used for authoritative restore and the time of the restore procedure. 247

Objects and attributes are preserved during authoritative restore as follows: • If an object exists in the backup, before inbound replication the post-restore directory partition contains the version of the object that exists in the restored backup. • If an object was created after the backup was made and there are additional domain controllers that store the directory partition, after inbound replication the restored directory partition also includes the set of objects that were created after the backup. • If an object contains new attributes that are not contained in the backup but that exist in the directory partition of an additional domain controller in the domain at the time of the restore, after inbound replication the version of the object and attributes as they existed in the backup— plus any new attributes that were added to the object after the backup—are preserved. Authoritative restore affects only the objects and attributes that existed at the time of the backup. This functionality applies to objects with linked attributes and nonlinked attributes alike. For example, if you are restoring an object that has attribute A and attribute B in the backup version and has attributes A’, B’, and C in the current directory, attribute C is retained after authoritative restore. Therefore, a group object that has the member value of User1 in the backup and has both User1 and User2 in the current directory includes both of those memberships after authoritative restore of the group object. Any post-backup memberOf or member attribute values that were added to a user or group, respectively, are not affected by replication updates after the restore procedure. If you want to remove group memberships—or any other unwanted object attribute—complete the following steps: 1. Delete the object whose updates you do not want to retain. 2. Allow the deletion to replicate throughout the forest. 3. Back up a domain controller that has received the deletion. 4. Authoritatively restore the object that you deleted from the backup that does not contain the unwanted values.

Authoritative restore procedures
Procedures for this task restore deleted objects and back-links for the restored objects in the domain of the deletions. If you are restoring security principals that might belong to groups in more than one domain or if you are restoring other objects that have back-links to objects in another domain, additional steps are required. Task requirements The following tools are required to perform the procedures for this task: • • • • • Repadmin.exe Remote Desktop Connection (optional) Bcdedit.exe (optional) Ntdsutil.exe Procedures for restoring after deletions have replicated 248

To complete this task, perform procedures according to the conditions in your environment:



Procedures for restoring before deletions have replicated

• Procedures for recovering group memberships (and any other back-link attributes) in other domains

Procedures for restoring after deletions have replicated
If you are performing authoritative restore on a domain controller that has already received replication of the deletions, perform the following procedures on the recovery domain controller: 1. If you do not have a current backup of the recovery domain controller, Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin). You can use this backup if your recovery is not successful and then try again. 2. Restart the Domain Controller in Directory Services Restore Mode Locally Or Restart the Domain Controller in Directory Services Restore Mode Remotely Restore from backup requires restarting the domain controller in DSRM. Taking the domain controller offline by stopping AD DS is not sufficient to run Ntdsutil procedures to restore from backup. 3. Restore AD DS from Backup (Nonauthoritative Restore) Use this procedure to return the domain controller to its state at the time of the backup so that any groups that are being restored—or whose members are being restored—are present in the directory with their predeletion membership intact. When Ntdsutil.exe generates the .ldf file during authoritative restore, it searches for member attributes that refer to objects that are contained in the text file, which contains the objects that are marked for authoritative restore. To ensure that replication does not occur, do not restart the domain controller after the restore procedure. 4. Mark an Object or Objects as Authoritative Mark the object or objects that you want to restore so that replication does not overwrite them when you restart the domain controller. 5. Restart the domain controller normally. 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 outbound replication must occur from the domain controller that originates the restored changes to 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. Run an LDIF File to Recover Back-Links in this domain. This procedure updates the group memberships of a restored security principal object or container of objects in the recovery domain. Perform this procedure for each individual object or container that you marked as authoritative.

249

8. If the .ldf file shows back-links for objects in other domains, perform the procedures in Procedures for recovering group memberships (and any other back-link attributes) in other domains.

Procedures for restoring before deletions have replicated
If you have identified a global catalog server or other domain controller that has not received replication of the deletions and for which you have a recent backup, you do not have to perform a preliminary restore from backup. You do not have to perform the authoritative restore procedure in DSRM. Instead, you can stop the AD DS service. Perform the following procedures on the recovery domain controller: 1. Turn Off Inbound Replication. Leave inbound replication turned off until you have finished marking objects that you want to replicate authoritatively. 2. If you do not have a current backup of the recovery domain controller, Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin). You can use this backup if your recovery is not successful and then try again. 3. Use the Services snap-in to stop AD DS. 4. Mark an Object or Objects as Authoritative Mark the object or objects that you want to restore so that replication does not overwrite them when you restart the domain controller. 5. Use the Services snap-in to restart AD DS. 6. Synchronize Replication with All Partners For the authoritatively marked objects to become available and be instantiated on all domain controllers, successful outbound replication must occur from the domain controller that originates the authoritative changes to its partners. Make sure that all domain controllers in the domain and all global catalog servers in the forest have received replication of the authoritative objects. 7. Run an LDIF File to Recover Back-Links in this domain. This procedure updates the group memberships of a restored security principal object or a container of objects in the recovery domain. Perform this procedure for each individual object or container that you marked as authoritative. 8. Turn on Inbound Replication. 9. Back up the recovered domain controller. See Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) (http://go.microsoft.com/fwlink/? LinkId=118357) or Perform a Backup of Critical Volumes of a Domain Controller by Using the GUI (Windows Server Backup) (http://go.microsoft.com/fwlink/?LinkId=116312). 10. If the .ldf file shows back-links for objects in other domains, complete the procedures in Procedures for recovering group memberships (and any other back-link attributes) in other domains.

250

Procedures for recovering group memberships (and any other back-link attributes) in other domains
You can recover group memberships in other domains either by adding the members manually to the respective groups or by using the text file from the original authoritative restore procedure to generate one or more .ldf files that you can use to recover back-links in other domains. Be aware that restored objects might have back-links other than group memberships. If you have restored security principal objects or other objects that have back-link attributes in a forest that has more than one domain and you do not want to restore the back-links manually, perform the following steps on a domain controller in each additional domain: Note For restored security principals, these steps are required only if the restored security principals have memberships in domain local or universal groups in a different domain from the recovery domain. If you restored the security principals on a global catalog server, you need to recover only domain local group memberships in other domains. In some cases, these accounts might be few enough that you can manually recreate the memberships instead of following these procedures. 1. Restart the Domain Controller in Directory Services Restore Mode Locally Or Restart the Domain Controller in Directory Services Restore Mode Remotely 2. Restore AD DS from Backup (Nonauthoritative Restore) When the group members were deleted, the member attribute (forward link) on any group of which they were members was removed from the group object. This procedure is required to restore the member attribute on group objects for those group members that were deleted. This attribute is required to regenerate the memberOf attribute value on the restored group members. 3. While still in DSRM, use Ntdsutil to Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects. In this procedure, you must specify the location of the .txt file that was generated by Ntdsutil during the authoritative restore procedure. 4. Restart the domain controller normally. 5. Run an LDIF File to Recover Back-Links in this domain on a domain controller other than the domain controller that you restored from backup and on which you created the LDIF file. Because you have just restored the domain controller on which you created the LDIF file from backup, perform this procedure on a different domain controller to be sure that the group objects you update are current. This procedure updates the group memberships of a restored security principal object or container of objects. Perform this procedure for each individual object or container that you marked as authoritative.

Additional references
• Known Issues for Authoritative Restore 251



Best Practices for Authoritative Restore

Known Issues for Authoritative Restore
Review the following known issues before you perform an authoritative restore on domain controllers running Windows Server 2008 in forests that have the forest functional level of Windows Server 2003, Windows Server 2003 interim, or Windows Server 2008: • • • Order of replication and dropped group memberships Members added back to groups from which they were deleted Incorrect assignment of Exchange mailboxes

Order of replication and dropped group memberships
When groups that are being restored were created or updated when the forest had a forest functional level of Windows Server 2003, Windows Server 2003 interim, or Windows Server 2008 (that is, when linked-value replication (LVR) was in effect), the version of Ntdsutil on domain controllers that are running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008 automatically restores group memberships during the authoritative restore procedure by restoring back-links to group objects. To restore back-links for pre-LVR groups, Ntdsutil generates an LDAP Data Interchange Format (LDIF) file (.ldf) that you must process by using the Ldifde.exe tool to manually restore the back-link values. However—of particular importance where group memberships are concerned—the order of replication can undo the benefits of authoritative restore in some cases. For this reason, we recommend always processing the .ldf file that is produced by Ntdsutil during authoritative restore to update group memberships, even if the group or groups being restored were created or updated when LVR was in effect. For information about LVR and its effects on the authoritative restore process, see Performing Authoritative Restore of Active Directory Objects. Updated, authoritatively marked objects replicate in a “store-and-forward” manner that might lead to the objects being received on one domain controller and forwarded to one or more other domain controllers. Regardless of the order in which replication is initiated, the order in which replicated updates are received cannot be guaranteed. For this reason, it is possible for authoritatively restored group objects to replicate ahead of authoritatively restored objects that are group members, which can result in dropped memberships. For example, suppose group A and its member User X are both deleted. And suppose User X and Group A are authoritatively restored and, during the authoritative restore procedure, Ntdsutil updates the member attribute of Group A to include authoritatively restored User X, and the memberOf attribute of User X to include Group A. If replication of Group A is received before replication of User X, User X is currently a deleted object on the recipient domain controller. In this case, the User X link value is dropped from the member attribute of Group A. When replication of 252

the authoritatively restored User X is received, perhaps only seconds later, the member attribute of the group is not updated. If replication of User X is received before Group A, the membership on Group A is retained. Use the following steps to ensure that group memberships for authoritatively restored groups and their restored members are always retained during replication after authoritative restore: 1. Ensure that all authoritatively restored objects have replicated and exist on all domain controllers in the domain. 2. Run the .ldf file on the recovery domain controller. 3. Force replication on the recovery domain controller.

Members added back to groups from which they were deleted
To recover memberships in groups in the recovery domain and in other domains in which a restored security principal might have group memberships, you process an .ldf file to restore the memberships. It is possible for the .ldf file to include memberships in groups from which a restored user object was removed before the backup that is used for the preliminary nonauthoritative restore. In this case, after authoritative restore, a user might have membership in a group from which the user was formerly removed. For more information, see article 951320 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=122656).

Incorrect assignment of Exchange mailboxes
Authoritative restore of deleted user accounts that have mailboxes in Microsoft Exchange 2003 can result in incorrect mailbox assignments after replication. For information about avoiding this issue, see article 948997 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/? LinkId=116275).

Best Practices for Authoritative Restore
The following best practices are provided to ensure successful recovery of the data that is being restored. Group membership is particularly sensitive. It can be affected greatly by the procedures that you follow during an authoritative restore. The following best practices help ensure successful recovery of data when you use them to perform authoritative restore: • Restore a latent domain controller. If possible, find a domain controller (preferably a global catalog server) that has not received replication of the deleted objects, and perform authoritative restore on that domain controller. In this case, you do not have to perform a preliminary nonauthoritative restore from backup. • Restore a global catalog server. 253

Attempt to find a global catalog server to use as the recovery domain controller. Only a global catalog server can recover universal group memberships for other domains. If you cannot find a latent global catalog server or other domain controller in the domain where the deletion occurred, find the most recent system state or critical-volume backup of a global catalog server in that domain. Use this global catalog server as the recovery domain controller. In addition, locate the most recent backup of a non-global-catalog domain controller. • Stop changes to groups. • You are restoring individual, deleted user or computer accounts by their distinguished name (DN) paths. • • • You are restoring a domain controller that has not received replication of the deletions. You are not restoring security groups or their parent containers. Stop making changes to security groups in the forest if all of the following statements are true:

Keep users and administrators informed.

If you are restoring security groups or organizational unit (OU) containers that host security groups or user accounts, notify users, administrators, and help desk administrators in the domain of the deletions—and in any other domains that might have group memberships for the deleted accounts—to temporarily stop all changes to these objects. • Create a preliminary backup. If system state or critical-volume backup is not current up to the point of the deletion, before you perform authoritative restore, create a new system state or critical-volume backup in the domain of the deletions. You can use this backup if you need to roll back your changes. • Select objects as low as possible in the directory tree. When you are selecting objects to mark for authoritative restore, find the lowest possible container or set of objects to restore so that you do not roll back objects unnecessarily. For more information, see Performing Authoritative Restore of Active Directory Objects. • Process the .ldf file after replication. After the authoritatively restored objects have replicated to all domain controllers in the domain, always use the Ldifde.exe tool to process the .ldf file that is generated by Ntdsutil. Even when memberships are being restored automatically by Ntdsutil for groups that use linked-value replication (LVR), processing the .ldf file ensures that memberships are retained when replicated. For more information about the effect of replication order on group memberships following authoritative restore, see Known Issues for Authoritative Restore. Note It is possible for the .ldf file to contain memberships in groups from which the restored security principal was removed before backup. For more information, see Known Issues for Authoritative Restore. • Perform follow-up steps. a. Verify group memberships in the domain of the recovery domain controller and on a global catalog server in every other domain. 254 After the authoritative restore procedure is complete, perform the following steps:

b. Create a new system state or critical-volumes backup in the recovery domain. c. Notify users, administrators, and help desk administrators that they can resume making changes. d. Instruct help desk administrators to reset the passwords of restored user accounts and computer accounts whose domain passwords changed after the restored backup was created.

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 (DSRM) locally. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not as a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Stepby-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). You can restart a domain controller in DSRM manually by pressing the F8 key during domain controller startup, which requires watching the startup and waiting for the appropriate point in the startup to press the key. This method is tedious and can waste time if you miss the brief window of opportunity for selecting the restart mode. On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally.

255

When you are finished managing a domain controller in DSRM, if you have used System Configuration or Bcdedit.exe to restart the domain controller in DSRM, you must change the configuration so that the domain controller restarts in normal mode. Note A benefit of using System Configuration or Bcdedit.exe for implementing restart of a domain controller into DSRM is that normally the domain controller cannot be inadvertently restarted. This benefit is particularly useful when you are performing a nonauthoritative restore from backup followed by an authoritative restore. You can also use System Configuration or Bcdedit.exe to restart a domain controller in DSRM remotely. To use System Configuration or Bcdedit.exe and Remote Desktop Connection to restart a domain controller in DSRM remotely, see Restart the Domain Controller in Directory Services Restore Mode Remotely. Membership in the Domain Admins group is the minimum required complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM is required to log on to the domain controller in DSRM. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728).

Restarting the domain controller in DSRM locally
You can use either of the following methods to restart the domain controller in DSRM: To restart a domain controller in DSRM locally by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click System Configuration. 2. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 3. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. 4. Perform procedures in DSRM. 5. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. 256

The domain controller restarts normally. To restart a domain controller in DSRM locally by using the command line 1. Click Start, click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

4. When you are still in DSRM and you are ready to restart in normal mode, open a command prompt and type the following, and then press ENTER:
bcdedit /deletevalue safeboot

5. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

Value

Description

/set safeboot dsrepair shutdown –t 0 -r /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Restart the Domain Controller in Directory Services Restore Mode Remotely

Restart the Domain Controller in Directory Services Restore Mode Remotely
If you have remote access to a domain controller, you can restart the domain controller in Directory Services Restore Mode (DSRM) remotely. Remote access requires the user right to log on locally to a domain controller. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account.

257

Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line or to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. To restart the domain controller in DSRM remotely, you first use Remote Desktop Connection to connect to the domain controller while it is in normal startup mode. Remote Desktop Connection must be enabled on the target domain controller. After the domain controller has restarted, you can use Remote Desktop Connection to reconnect to the domain controller and then log on as the local Administrator, using the DSRM password. You can use this procedure to connect to a domain controller remotely, restart it in DSRM, and then reconnect to it as the DSRM administrator. Membership in Domain Admins, or equivalent, is the minimum required to complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM and the user right to log on locally to a domain controller are required to log on to the domain controller in DSRM. Members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the user right to log on locally to a domain controller by default. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. Using a domain administrative account to log on to an RODC can compromise the server. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728).

258

To restart a domain controller in DSRM remotely by using the Windows GUI 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. On the Start menu, point to Administrative Tools, and then click System Configuration. 3. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 4. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 5. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 6. The domain controller name should still be showing in Computer. If it is not, select it from the list, and then click Connect. 7. In the Windows Security dialog box, click Use another account. 8. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 9. In Password, type the DSRM password, and then click OK. 10. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 11. Type MachineName\Administrator, and then press ENTER. 12. Perform procedures in DSRM. 13. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. This procedure will disconnect your remote session.

259

To restart a domain controller in DSRM remotely by using the command line 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. Open a command prompt. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 4. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 5. The domain controller name should still be showing in Computer. If it is not, select it in the list, and then click Connect. 6. In the Windows Security dialog box, click Use another account. 7. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 8. In Password, type the DSRM password, and then click OK. 9. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 10. Type MachineName\Administrator, and then press ENTER. 11. Perform procedures in DSRM. 12. When you have finished performing procedures in DSRM, restart the domain controller normally: a. In DSRM, open a command prompt, type the following command, and then press ENTER:
bcdedit /deletevalue safeboot

b. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 –r

The domain controller restarts normally. This procedure will disconnect your remote 260

session.
Value Description

bcdedit /set safeboot dsrepair shutdown –t 0 -r bcdedit /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Enable Remote Desktop Create a Remote Desktop Connection Restart the Domain Controller in Directory Services Restore Mode Locally

Restore AD DS from Backup (Nonauthoritative Restore)
Nonauthoritative restore from backup restores Active Directory Domain Services (AD DS) from its current state to the previous state of a backup. Use this procedure before you perform an authoritative restore procedure to recover objects that were deleted after the time of the backup. To restore AD DS from backup, use a system state or critical-volumes backup. To restore AD DS from backup, you must restart the domain controller in Directory Services Restore Mode (DSRM). Note If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). Be sure that you know the name and location of the version of the backup that you are restoring. Backup files are named for the date and time of the backup. When you restore the backup, the version must be stated in the form MM/DD/YYYY-HH:MM (month/day/year-hour:minute), which specifies the name of backup that you want to restore. The Wbadmin.exe command-line tool does not require that you provide the target for the recovery. By specifying the backup version that you want to recover, the command proceeds to recover to the source location of the backup version that you specify. Note The systemstaterecovery command in Wbadmin.exe causes a nonauthoritative restore of SYSVOL by default (only updates to SYSVOL since the time of the backup are replicated to 261

the recovery domain controller). If you want to restore SYSVOL authoritatively (all of SYSVOL is replicated from the recovery domain controller to other domain controllers in the domain), specify the –authsysvol option in the command. The Administrator password for DSRM is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. The server must be running in DSRM. To perform a nonauthoritative restore of AD DS 1. At the Windows logon screen, click Switch User, and then click Other User. 2. Type .\administrator as the user name, type the DSRM password for the server, and then press ENTER. 3. Open a Command Prompt. 4. At the command prompt, type the following command, and then press ENTER:
wbadmin get versions -backuptarget:<targetDrive>: -machine:<BackupComputerName>

Where: •
<targetDrive>:

is the location of the backup that you want to restore.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was made. 5. Identify the backup version that you want to restore. You must enter this backup version exactly in the next step. 6. At the command prompt, type the following command, and then press ENTER:
wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM> -backuptarget:<targetDrive>: -machine:<BackupComputerName> -quiet

Where: • •
<MM/DD/YYYY-HH:MM> <targetDrive>:

is the version of the backup that you want to restore.

is the volume that contains the backup.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was taken. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the restore process and then press Y to confirm that the replication engine for SYSVOL has not changed since you created the backup. After the recovery operation is complete, if you are not going to perform an authoritative restore of any restored objects, restart the server.

262

Additional references
• • • • • 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 Performing Authoritative Restore of Active Directory Objects

Mark an Object or Objects as Authoritative
You can use this procedure to mark Active Directory objects as authoritative when you perform an authoritative restore. In this procedure, you use the ntdsutil command to select objects that are to be marked authoritative when they replicate to other domain controllers. This procedure has the following preliminary requirements: • You must know the full distinguished name of the object or objects that you want to restore. • If the deletions that you are recovering have replicated to the recovery domain controller, you must have completed a nonauthoritative restore procedure, after which you did not restart the domain controller and it remains in Directory Services Restore Mode (DSRM). • If the deletions that you are recovering have not replicated to the recovery domain controller, you can perform this procedure in normal mode with Active Directory Domain Services (AD DS) stopped. The Ntdsutil functionality that is described in this procedure is available on domain controllers that are running Windows Server 2008. To perform authoritative restore on a domain controller that is running a version of Windows Server 2003, see Performing an Authoritative Restore of Active Directory Objects (http://go.microsoft.com/fwlink/?LinkId=44194). Note If you are able to stop inbound replication on a global catalog server or other domain controller in the domain before it has received the deletion that you want to restore, you can skip the nonauthoritative restore process. Perform this procedure to recover deleted objects in the domain and to restore back-links for those objects in this domain. If you are running the authoritative restore procedure on a global catalog server, back-links for objects in other domains are also updated if the forward link is stored in the global catalog. For example, the values for back-link attribute memberOf are restored in this procedure if the forward link member is stored in the global catalog or in the domain directory partition. In the case of domain local groups, the member attribute is not stored in the global catalog and it is not stored in the recovery domain if the group exists in a different domain. In this case, you must perform additional steps to recover domain local group memberships of restored security principals. These steps are described in Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects

263

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To mark a subtree or individual object authoritative 1. In DSRM, 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 (OU) and all child objects):
restore subtree <DistinguishedName>

To restore a single object:
restore object <DistinguishedName>

Where <DistinguishedName> is 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 OU 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. (This occurs if you try to restore a deleted object that was created after the backup). The following sample output shows that Ntdsutil created a text file (.txt) and an LDAP Data Interchange Format (LDIF) (.ldf) file 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_20080209-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_20080209-091249_links_Corp.Contoso.com.ldf

264

Authoritative Restore completed successfully.

5. Make a note of the location of the .txt and .ldf files, if any. We recommend that you use the .ldf file to restore back-links in this domain, even if restored objects are members of groups that were created before linked-value replication (LVR) was in effect. However, in all cases where any of the restored objects listed in the .txt file has memberships in groups in a different domain, you must use the .txt file to generate an .ldf file to restore back-links in those domains. 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 each additional domain. 6. At the authoritative ENTER.
restore:

and ntdsutil: prompts, type quit, and then press

7. Restart the domain controller in normal operating mode.

Additional references
• Run an LDIF File to Recover Back-Links

Turn Off Inbound Replication
You can use this procedure and the repadmin command to turn off inbound replication so that Active Directory objects on a domain controller cannot be updated by replication from another domain controller. You can manage the inbound replication state by setting a repadmin option to change the value in DISABLE_INBOUND_REPL. You change the state is by using a plus (+) to enable the disabled state (turn off inbound replication) and a minus (–) to disable (reverse) the disabled state (turn on inbound replication). When you apply the option, the command output confirms only that the DISABLE_INBOUND_REPL option is either new or current. It does not indicate “on” or “off.” Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To turn off inbound replication 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if requested, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /options <ServerName> +DISABLE_INBOUND_REPL

265

where <ServerName> is the NetBIOS name of the domain controller. 3. Verify that the DISABLE_INBOUND_REPL option is in effect. The following message should appear:
Current DSA options: <Whatever options are set> New DSA Options: DISABLE_INBOUND_REPL

displays the conditions that were in effect at the time that you ran the command. New DSA Options shows the effect of the command, which is that the DISABLE_INBOUND_REPL option is now in effect.
Current DSA Options

Additional references
• Turn on Inbound Replication

Synchronize Replication with All Partners
You can use this procedure to synchronize replication with all replication partners of a domain controller. Membership in Enterprise Admins in the forest or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To synchronize replication with all partners 1. At a command prompt, type the following command, and then press ENTER:
repadmin /syncall <DomainControllerName> /e /d /A /P /q

266

Value

Description

repadmin /syncall <DomainControllerName>

Synchronizes a specified domain controller with all replication partners. The Domain Name System (DNS) name of the domain controller on which you want to synchronize replication with all partners. Enterprise; includes partners in all sites. Identifies servers by their distinguished names 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
When you perform an authoritative restore on a domain controller that is running Windows Server 2008, Windows Server 2003 R2, Windows Server 2003 with Service Pack 1 (SP1), or Windows Server 2003 with Service Pack 2 (SP2), the output of the authoritative restore procedure includes an LDAP Data Interchange Format (LDIF) (.ldf) file. This .ldf file contains information about the forward-links that are required so that the group memberships (back-links) of any restored user, group, or computer objects in Active Directory Domain Services (AD DS) can be recovered in the domain in which the deletions occurred. You can use this procedure to run an .ldf file to recover back-links for Active Directory objects. Restore group memberships in the domain of the deletions For each object or subtree that you authoritatively restore, run the .ldf file on the restored domain controller to recover group memberships in the domain of the deletions. 267

Restore group memberships in other domains To recover group memberships in other domains in the forest, you must first generate an .ldf file in that domain, as described in Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects. Then, use this procedure in the respective domain to recover back-links. When you recover group memberships in domains other than the domain of the deletions, you first perform a nonauthoritative restore of the domain controller to return AD DS to a state in which it contained the deleted memberships and then use the .txt file to generate the .ldf file. The domain controller that you restore from backup has old data until it has finished replicating from another domain controller in the domain. If you add users to groups on the restored computer before it is up to date, you might lose some of the changes that you make when this domain controller is updated through inbound replication. For this reason, run the .ldf file on a different, up-to-date domain controller in the same domain. 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. This procedure explains how to use the Ldifde tool and an .ldf file to recover back-links for authoritatively restored objects in a single domain. Perform this procedure on an up-to-date domain controller in the domain of the group or groups whose memberships you are recovering. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To run an .ldf file to recover back-links after authoritative restore 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 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>

Where <FileName> is the name of the .ldf file that you want to run, for example, ar_20080609-174604_links_corp.contoso.com.ldf.

Additional references
• Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects

268

Turn on Inbound Replication
You can use the repadmin command-line tool in this procedure to turn on inbound Active Directory replication after it has been turned off manually. You can manage the inbound replication state by setting a repadmin option to change the value in DISABLE_INBOUND_REPL. You change the state by using a plus (+) to enable the disabled state (turn off inbound replication) and a minus (–) to disable (reverse) the disabled state (turn on inbound replication). When you apply the option, the command output confirms only that the DISABLE_INBOUND_REPL option is either new or current. It does not indicate “on” or “off.” Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To turn on inbound replication 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if requested, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /options <ServerName> -DISABLE_INBOUND_REPL

Where <ServerName> is the NetBIOS name of the domain controller. 3. Verify that the DISABLE_INBOUND_REPL option is not in effect. The following message should appear:
Current DSA options: DISABLE_INBOUND_REPL New DSA Options: <none>

displays the conditions that were in effect at the time that you ran the command. New DSA Options shows the effect of the command, which is that the DISABLE_INBOUND_REPL option is not in effect (does not appear).
Current DSA Options

Additional references
• Turn Off Inbound Replication

Create an LDIF File for Recovering BackLinks for Authoritatively Restored Objects
When you perform an authoritative restore in a domain where deletions of Active Directory objects occurred, the Ntdsutil tool generates a text (.txt) file that identifies the objects that have been

269

restored. You can use this .txt file to generate an LDAP Data Interchange Format (LDIF) file (.ldf) in other domains that might have back-links from the restored objects. This procedure generates the .ldf file that you need to recover back-links in this domain. Perform this procedure on a domain controller in the domain that might have the back-links.After you complete this procedure, you must use the Ldifde tool to run the .ldf file on a domain controller in the same domain, as described in Run an LDIF File to Recover Back-Links. Note To ensure that current group objects are updated, run the .ldf file on a domain controller other than the domain controller that you use to generate the .ldf file. 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. After you restore this domain controller from backup, perform this procedure while the domain controller is still running in Directory Services Restore Mode (DSRM). To perform this procedure, you must provide the Administrator password for DSRM. To create an .ldf file for restoring back-links for authoritatively restored objects 1. In DSRM, click Start, click Run, type ntdsutil, and then press ENTER. 2. At the ntdsutil: prompt, type authoritative 3. At the authoritative ENTER:
restore: restore,

and then press ENTER.

prompt, type the following command, and then press

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_20080609_091558_objects.txt. Ntdsutil displays a message stating that one or more specified objects have back-links in this domain and an .ldf file has been created in the current working directory. 4. At the authoritative
restore:

and ntdsutil: prompts, type quit.

Additional references
• • Restore AD DS from Backup (Nonauthoritative Restore) Run an LDIF File to Recover Back-Links

270

Performing Authoritative Restore of an Application Directory Partition
A restore of an application directory partition marks all data that is present in the partition as authoritative for the replica set. The information that an application directory partition contains replicates 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 directory partition before you begin the authoritative restore, in the event that particular object changes are lost because of changes since the backup was created. If you deleted an entire application directory partition, you must perform the restore procedure on the domain naming operations master role holder. Before you perform the procedures in this task, back up the domain controller that you are restoring. For information about creating backups, see Backing Up Active Directory Domain Services. Task requirements The following tools are required to perform the procedures for this task: • • • Remote Desktop Connection (optional) Bcdedit.exe (optional) Ntdsutil.exe

To complete this task, perform the following procedures: 1. Restart the domain controller in Directory Services Restore Mode (DSRM), as follows: Restart the Domain Controller in Directory Services Restore Mode Locally Or Restart the Domain Controller in Directory Services Restore Mode Remotely 2. Restore AD DS from Backup (Nonauthoritative Restore). Do not restart the domain controller. 3. Mark an application directory partition as authoritative 4. Restart the domain controller normally.

Restart the Domain Controller in Directory Services Restore Mode Remotely
If you have remote access to a domain controller, you can restart the domain controller in Directory Services Restore Mode (DSRM) remotely. Remote access requires the user right to log on locally to a domain controller. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not a domain controller.

271

During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line or to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. To restart the domain controller in DSRM remotely, you first use Remote Desktop Connection to connect to the domain controller while it is in normal startup mode. Remote Desktop Connection must be enabled on the target domain controller. After the domain controller has restarted, you can use Remote Desktop Connection to reconnect to the domain controller and then log on as the local Administrator, using the DSRM password. You can use this procedure to connect to a domain controller remotely, restart it in DSRM, and then reconnect to it as the DSRM administrator. Membership in Domain Admins, or equivalent, is the minimum required to complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM and the user right to log on locally to a domain controller are required to log on to the domain controller in DSRM. Members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the user right to log on locally to a domain controller by default. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. Using a domain administrative account to log on to an RODC can compromise the server. 272

For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). To restart a domain controller in DSRM remotely by using the Windows GUI 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. On the Start menu, point to Administrative Tools, and then click System Configuration. 3. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 4. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 5. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 6. The domain controller name should still be showing in Computer. If it is not, select it from the list, and then click Connect. 7. In the Windows Security dialog box, click Use another account. 8. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 9. In Password, type the DSRM password, and then click OK. 10. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 11. Type MachineName\Administrator, and then press ENTER. 12. Perform procedures in DSRM. 13. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. 273

The domain controller restarts normally. This procedure will disconnect your remote session. To restart a domain controller in DSRM remotely by using the command line 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. Open a command prompt. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 4. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 5. The domain controller name should still be showing in Computer. If it is not, select it in the list, and then click Connect. 6. In the Windows Security dialog box, click Use another account. 7. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 8. In Password, type the DSRM password, and then click OK. 9. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 10. Type MachineName\Administrator, and then press ENTER. 11. Perform procedures in DSRM. 12. When you have finished performing procedures in DSRM, restart the domain controller normally: a. In DSRM, open a command prompt, type the following command, and then press ENTER:
bcdedit /deletevalue safeboot

274

b. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 –r

The domain controller restarts normally. This procedure will disconnect your remote session.
Value Description

bcdedit /set safeboot dsrepair shutdown –t 0 -r bcdedit /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Enable Remote Desktop Create a Remote Desktop Connection Restart the Domain Controller in Directory Services Restore Mode Locally

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 (DSRM) locally. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not as a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Stepby-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). You can restart a domain controller in DSRM manually by pressing the F8 key during domain controller startup, which requires watching the startup and waiting for the appropriate point in the

275

startup to press the key. This method is tedious and can waste time if you miss the brief window of opportunity for selecting the restart mode. On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. When you are finished managing a domain controller in DSRM, if you have used System Configuration or Bcdedit.exe to restart the domain controller in DSRM, you must change the configuration so that the domain controller restarts in normal mode. Note A benefit of using System Configuration or Bcdedit.exe for implementing restart of a domain controller into DSRM is that normally the domain controller cannot be inadvertently restarted. This benefit is particularly useful when you are performing a nonauthoritative restore from backup followed by an authoritative restore. You can also use System Configuration or Bcdedit.exe to restart a domain controller in DSRM remotely. To use System Configuration or Bcdedit.exe and Remote Desktop Connection to restart a domain controller in DSRM remotely, see Restart the Domain Controller in Directory Services Restore Mode Remotely. Membership in the Domain Admins group is the minimum required complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM is required to log on to the domain controller in DSRM. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728).

Restarting the domain controller in DSRM locally
You can use either of the following methods to restart the domain controller in DSRM: To restart a domain controller in DSRM locally by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click System 276

Configuration. 2. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 3. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. 4. Perform procedures in DSRM. 5. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. To restart a domain controller in DSRM locally by using the command line 1. Click Start, click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

4. When you are still in DSRM and you are ready to restart in normal mode, open a command prompt and type the following, and then press ENTER:
bcdedit /deletevalue safeboot

5. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

Value

Description

/set safeboot dsrepair shutdown –t 0 -r /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Restart the Domain Controller in Directory Services Restore Mode Remotely

277

Restore AD DS from Backup (Nonauthoritative Restore)
Nonauthoritative restore from backup restores Active Directory Domain Services (AD DS) from its current state to the previous state of a backup. Use this procedure before you perform an authoritative restore procedure to recover objects that were deleted after the time of the backup. To restore AD DS from backup, use a system state or critical-volumes backup. To restore AD DS from backup, you must restart the domain controller in Directory Services Restore Mode (DSRM). Note If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). Be sure that you know the name and location of the version of the backup that you are restoring. Backup files are named for the date and time of the backup. When you restore the backup, the version must be stated in the form MM/DD/YYYY-HH:MM (month/day/year-hour:minute), which specifies the name of backup that you want to restore. The Wbadmin.exe command-line tool does not require that you provide the target for the recovery. By specifying the backup version that you want to recover, the command proceeds to recover to the source location of the backup version that you specify. Note The systemstaterecovery command in Wbadmin.exe causes a nonauthoritative restore of SYSVOL by default (only updates to SYSVOL since the time of the backup are replicated to the recovery domain controller). If you want to restore SYSVOL authoritatively (all of SYSVOL is replicated from the recovery domain controller to other domain controllers in the domain), specify the –authsysvol option in the command. The Administrator password for DSRM is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. The server must be running in DSRM. To perform a nonauthoritative restore of AD DS 1. At the Windows logon screen, click Switch User, and then click Other User. 2. Type .\administrator as the user name, type the DSRM password for the server, and then press ENTER. 3. Open a Command Prompt. 4. At the command prompt, type the following command, and then press ENTER:
wbadmin get versions -backuptarget:<targetDrive>: -machine:<BackupComputerName>

278

Where: •
<targetDrive>:

is the location of the backup that you want to restore.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was made. 5. Identify the backup version that you want to restore. You must enter this backup version exactly in the next step. 6. At the command prompt, type the following command, and then press ENTER:
wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM> -backuptarget:<targetDrive>: -machine:<BackupComputerName> -quiet

Where: • •
<MM/DD/YYYY-HH:MM> <targetDrive>:

is the version of the backup that you want to restore.

is the volume that contains the backup.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was taken. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the restore process and then press Y to confirm that the replication engine for SYSVOL has not changed since you created the backup. After the recovery operation is complete, if you are not going to perform an authoritative restore of any restored objects, restart the server.

Additional references
• • • • • 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 Performing Authoritative Restore of Active Directory Objects

Mark an application directory partition as authoritative
If you are performing an authoritative restore to recover deletions in an application directory partition, you must mark the application directory partition as authoritative. Marking an application directory partition as authoritative requires a different procedure from the procedure that you use to mark other Active Directory objects as authoritative. You can use this procedure to select the 279

application directory partition that you want to replicate authoritatively to other domain controllers that host the application directory partition. This procedure has the following preliminary requirements: • Before you perform this procedure, back up the domain controller that you are restoring. You should have a current valid backup of the application directory partition before restoring in case some object changes are lost as the result of changes that have occurred since the backup that you are using to restore the domain controller was made. • If the entire application directory partition has been deleted, you must perform a nonauthoritative restore from backup on the domain naming operations master. • You must have completed a nonauthoritative restore procedure, after which the domain controller has not been restarted and remains in Directory Services Restore Mode (DSRM). The Ntdsutil functionality that is described in this procedure is available on domain controllers that are running Windows Server 2008. To perform authoritative restore on a domain controller that is running a version of Windows Server 2003, see Performing an Authoritative Restore of Active Directory Objects (http://go.microsoft.com/fwlink/?LinkId=44194). If you are performing this procedure in DSRM, the Administrator password for DSRM is the minimum required to complete this procedure. If you are performing this procedure with AD DS stopped on the domain controller, membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To mark an application directory partition as authoritative 1. Open a Command Prompt. 2. At the command prompt, type the following command, and then press ENTER:
ntdsutil

3. At the ntdsutil: prompt, type activate instance ntds, and then press ENTER. For assistance with the Ntdsutil command line-tool, type help at any time. 4. At the ntdsutil: prompt, type authoritative 5. At the authoritative
restore: restore,

and then press ENTER. and then press ENTER.

prompt, type List

NC CRs,

Ntdsutil displays a list of directory partition distinguished names and their associated crossreference object distinguished names. Note the cross-reference distinguished name and application directory partition distinguished name that correspond to the application directory partition that you want to restore. 6. Type restore subtree <App Partition DN>, where <App Partition DN> is the distinguished name of the application directory partition that you want to restore. 7. In the confirmation dialog box, click Yes. The output message indicates the status of the operation. There should be no failures. 8. Type restore object <Cross Ref DN>, where <Cross Ref DN> is the distinguished name of the cross-reference object for the application directory partition that you want to restore, and then press ENTER. 280

9. In the confirmation dialog box, click Yes. The output message indicates the status of the operation. There should be no failures. 10. Quit the Ntdsutil tool by typing quit at each prompt.

See Also
Backing Up Active Directory Domain Services

Performing a Full Server Recovery of a Domain Controller
When you perform a full server recovery, you recover all volumes from the backup set to the server. The procedure to perform full server recovery of a domain controller is the same as for any server running Windows Server 2008. Whenever you perform a full server recovery of a domain controller, you perform a nonauthoritative restore of Active Directory Domain Services (AD DS). You can use these procedures to perform full server recovery of a domain controller by using Windows Complete PC Restore (a graphical user interface (GUI) tool) and Wbadmin.exe from the command line.

Requirements for performing a full server recovery of a domain controller
Full server recovery of a domain controller has the following requirements: • You must have a full server backup available. This type of backup contains all volumes that were on the server at the time that you made the backup. • You can store the backup on a separate, internal or external hard drive or a DVD. If you performed a manual backup, you can perform a full server recovery from a network shared folder. Note Windows Server Backup does not enumerate drives that are not attached or turned on when you start the Recovery Wizard. If you attach or turn on a drive after you start the wizard, and you do not see it in the list of backup locations that you can restore from, close, and then restart Windows Server Backup. • You must have the Windows Server 2008 operating system DVD or have Windows RE installed on a different partition than the critical partitions that are used by the domain controller that you are restoring. • If you are recovering to new hardware, the new hardware must provide enough storage capacity to recover all volumes. In other words, the hard drives that you are recovering data to must be as large as—or larger than—the drives that are included in the backup set. 281

Performing a full server recovery of a domain controller by using the GUI
You can use this procedure to perform full server recovery of a domain controller with Windows Complete PC Restore. There are no administrative credential requirements. No authentication is performed when you start in Windows RE. To perform full server recovery of a domain controller (a nonauthoritative restore) by using the GUI 1. Insert the Windows Server 2008 installation DVD into the disk drive, and then restart the domain controller. 2. When you are prompted, press a key to start from the DVD. 3. At the initial Windows screen, accept or select language options, the time and currency format, and a keyboard layout, and then click Next. 4. At the Install now screen, click Repair your computer. 5. In the System Recovery Options dialog box, click anywhere to clear any operating systems that are selected for repair, and then click Next. 6. Under Choose a recovery tool, click Windows Complete PC Restore. 7. If the backup is stored on a remote server, a message indicates that Windows cannot find a backup on the hard disks or DVDs on this computer. Click Cancel to close the message. 8. Click Restore a different backup, and then click Next. 9. On the Select the location of the backup page, perform either set of the following steps, depending on whether the backup is stored locally or on a network shared folder: a. If the backup is stored on the local computer, select the location of the backup, and then click Next. Or b. If the backup is stored on a network shared folder, click Advanced, and then click Search for a backup on the network. c. Click Yes to confirm that you want to connect to the network. d. In Network Folder, type the Universal Naming Convention (UNC) name for the network share, and then click OK. e. Type credentials for a user account that has sufficient permissions to restore the backup, and then click OK. f. On the Select the location of the backup page, click the location of the backup, and then click Next. 10. Click the backup to restore, and then click Next. 11. If you want to replace all data on all volumes, regardless of whether they are included in the backup, on the Choose how to restore the backup page, select the Format and 282

repartition disks check box. 12. To prevent volumes that are not included in the restore from being deleted and recreated, click Exclude Disks, select the check box for the disks that you want to exclude, and then click OK. 13. Click Next, and then click Finish. 14. Select the I confirm that I want to format the disks and restore the backup check box, and then click OK.

Performing a full server recovery of a domain controller by using the command line
Use the following procedure to perform full server recovery of a domain controller from the command line. There are no administrative credential requirements. No authentication is performed when you start in Windows RE. To perform full server recovery of a domain controller (a nonauthoritative restore) by using the command line 1. Insert the Windows Server 2008 installation DVD into the disk drive, and then restart the domain controller. 2. When you are prompted, press a key to start from the DVD. 3. At the initial Windows screen, accept or select language options, the time and currency format, and a keyboard layout, and then click Next. 4. At the Install now screen, click Repair your computer. 5. In the System Recovery Options dialog box, click anywhere to clear any operating systems that are selected for repair, and then click Next. 6. Under Choose a recovery tool, click Command Prompt. 7. At the Sources prompt, type diskpart, and then press ENTER. 8. At the Diskpart prompt, type list
vol,

and then press ENTER.

9. Identify the volume from the list that corresponds to the location of the full server backup that you want to restore. The drive letters in Windows RE do not necessarily match the volumes as they appear in Windows Server 2008. 10. Type exit, and then press ENTER. 11. At the Sources prompt, type the following command, and then press ENTER:
wbadmin get versions -backupTarget:<targetDrive>: -machine:<BackupComputerName>

Where: •
<targetDrive>:

is the location of the backup that you want to restore. 283

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is required, if the backup is stored on a remote computer. 12. Identify the version that you want to restore. You must enter this version exactly in the next step. 13. At the Sources prompt, type the following command, and then press ENTER:
wbadmin start sysrecovery -version:<MM/DD/YYYY-HH:MM> -backuptarget:<targetDrive>: -machine:<BackupComputerName> -restoreAllVolumes

Where: • •
<MM/DD/YYYY-HH:MM> <targetDrive>:

is the version of the backup that you want to restore.

is the drive that contains the backup.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was taken. 14. When you are prompted, press Y to proceed with the restore process. 15. After the recovery operation has completed, minimize the command window, and then, in the System Recovery Options dialog box, click Restart.

Additional considerations
Be aware of the following issues when you perform a full server recovery of a domain controller: • Wbadmin.exe does not require that you provide the recovery target. By specifying the backup version that you want to recover, the command proceeds to recover to the source location of the specified backup version. • Backup files are named for the date and time of the backup. When you recover, the version must be stated in the form MM/DD/YYYY-HH:MM, which specifies the name of the backup that you want to recover. • After the restore is completed, restart the server normally, and perform basic verification. When you restart the computer normally, AD DS and Active Directory Certificate Services (AD CS) automatically detect that they have been recovered from a backup. They perform an integrity check and index the database again. • After you log on to the system, browse AD DS. Verify that the following conditions are met: • All of the user objects and group objects that were present in the directory at the time of the backup are restored. Note Active Directory replication updates the objects that you restore with any changes that have been made to them since the time that the backup was taken. • Files that were members of a File Replication Service (FRS) replica set and certificates that were issued by AD CS are present. 284

• • •

The Windows Time service (W32time) is synchronized correctly. The NETLOGON and SYSVOL folders are properly shared. The Preferred DNS server address is configured correctly.

• Host (A) and service (SRV) resource records are registered correctly in Domain Name System (DNS).

Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup
If you cannot restart a domain controller in Directory Services Restore Mode (DSRM), you can restore it through reinstallation of the operating system and subsequent restore of Active Directory Domain Services (AD DS) from backup. After you reinstall Windows Server 2008, perform a nonauthoritative restore of a system state or critical-volumes backup. You must have a previous backup for the failed domain controller, and the backup cannot be older than the tombstone lifetime for the forest. You do not have to join the computer to the domain before you perform the restore procedure. During the restore, the computer account is reestablished automatically. Note You must perform the restore procedure by using the same backup tool with which the backup was made. Procedures in this task describe using Windows Server Backup to restore AD DS, but you must use the tool that you used to create the backup file if it is not Windows Server Backup. Task requirements To perform the domain controller restore procedure, you must 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 2008 must be reinstalled to the same drive letter and with at least the same amount of physical drive space as for the original installation. 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 it 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. • DSRM Administrator password. You must know the DSRM Administrator password that was in use when the backup was created. The following tools are required to perform the procedures for this task: 285

• • •

Remote Desktop Connection (optional) Bcdedit.exe (optional) Wbadmin.exe

To complete this task, perform the following procedures: 1. After you configure the disks appropriately, install Windows Server 2008. Note This guide does not provide information about installing Windows Server 2008. For information about installing Windows Server 2008, see Installing Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=111104). 2. Restart the server in DSRM by using one of the following methods: Note Restarting a member server in DSRM is not possible in Windows Server 2003, but it is possible in Windows Server 2008. Restart the Domain Controller in Directory Services Restore Mode Locally Or Restart the Domain Controller in Directory Services Restore Mode Remotely 3. Restore AD DS from Backup (Nonauthoritative Restore) 4. Verify AD DS restore

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 (DSRM) locally. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not as a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Stepby-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). 286

You can restart a domain controller in DSRM manually by pressing the F8 key during domain controller startup, which requires watching the startup and waiting for the appropriate point in the startup to press the key. This method is tedious and can waste time if you miss the brief window of opportunity for selecting the restart mode. On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. When you are finished managing a domain controller in DSRM, if you have used System Configuration or Bcdedit.exe to restart the domain controller in DSRM, you must change the configuration so that the domain controller restarts in normal mode. Note A benefit of using System Configuration or Bcdedit.exe for implementing restart of a domain controller into DSRM is that normally the domain controller cannot be inadvertently restarted. This benefit is particularly useful when you are performing a nonauthoritative restore from backup followed by an authoritative restore. You can also use System Configuration or Bcdedit.exe to restart a domain controller in DSRM remotely. To use System Configuration or Bcdedit.exe and Remote Desktop Connection to restart a domain controller in DSRM remotely, see Restart the Domain Controller in Directory Services Restore Mode Remotely. Membership in the Domain Admins group is the minimum required complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM is required to log on to the domain controller in DSRM. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/? LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728).

Restarting the domain controller in DSRM locally
You can use either of the following methods to restart the domain controller in DSRM:

287

To restart a domain controller in DSRM locally by using the Windows GUI 1. On the Start menu, point to Administrative Tools, and then click System Configuration. 2. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 3. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. 4. Perform procedures in DSRM. 5. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. To restart a domain controller in DSRM locally by using the command line 1. Click Start, click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

4. When you are still in DSRM and you are ready to restart in normal mode, open a command prompt and type the following, and then press ENTER:
bcdedit /deletevalue safeboot

5. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

Value

Description

/set safeboot dsrepair shutdown –t 0 -r /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

288

See Also
Restart the Domain Controller in Directory Services Restore Mode Remotely

Restart the Domain Controller in Directory Services Restore Mode Remotely
If you have remote access to a domain controller, you can restart the domain controller in Directory Services Restore Mode (DSRM) remotely. Remote access requires the user right to log on locally to a domain controller. Restarting in DSRM takes the domain controller offline. In this mode, the server is functioning as a member server, not a domain controller. During installation of Active Directory Domain Services (AD DS), you set the Administrator password for logging on to the server in DSRM. When you start Windows Server 2008 in DSRM, you must log on by using this DSRM password for the local Administrator account. Note By default, you must start a domain controller in DSRM to log on by using the DSRM Administrator account. However, on domain controllers that are running Windows Server 2008, you can change this behavior by modifying the DSRMAdminLogonBehavior registry entry. By changing the value for this entry, you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason. For more information about changing this registry entry, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). On domain controllers that are running Windows Server 2008, tools are available that replace the Boot.ini file that is used in earlier versions of Windows Server to modify the boot configuration parameters and controls. You can use the Windows graphical user interface (GUI) or the command line or to restart the domain controller in DSRM: • Windows GUI: System Configuration (Msconfig.msc) is an administrative tool that you can use to configure boot and startup options, including restarting in DSRM and normal mode. • Command line: Bcdedit.exe is a command-line tool that you can use to modify the boot configuration on a server that is running Windows Server 2008. You can use Bcdedit with shutdown commands to instruct the domain controller to restart in DSRM and to restart normally. To restart the domain controller in DSRM remotely, you first use Remote Desktop Connection to connect to the domain controller while it is in normal startup mode. Remote Desktop Connection must be enabled on the target domain controller. After the domain controller has restarted, you can use Remote Desktop Connection to reconnect to the domain controller and then log on as the local Administrator, using the DSRM password. You can use this procedure to connect to a domain controller remotely, restart it in DSRM, and then reconnect to it as the DSRM administrator. 289

Membership in Domain Admins, or equivalent, is the minimum required to complete the System Configuration (Windows GUI) or Bcdedit (command-line) procedure. The Administrator account and password for DSRM and the user right to log on locally to a domain controller are required to log on to the domain controller in DSRM. Members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the user right to log on locally to a domain controller by default. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Important If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. Using a domain administrative account to log on to an RODC can compromise the server. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). To restart a domain controller in DSRM remotely by using the Windows GUI 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. On the Start menu, point to Administrative Tools, and then click System Configuration. 3. On the Boot tab, in Boot options, select Safe boot, click Active Directory repair, and then click OK. 4. In the System Configuration dialog box, click Restart. The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 5. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 6. The domain controller name should still be showing in Computer. If it is not, select it from the list, and then click Connect. 7. In the Windows Security dialog box, click Use another account. 8. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller. 9. In Password, type the DSRM password, and then click OK. 290

10. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 11. Type MachineName\Administrator, and then press ENTER. 12. Perform procedures in DSRM. 13. When you have finished performing procedures in DSRM, restart the domain controller normally: a. On the Start menu, point to Administrative Tools, and then click System Configuration. b. On the General tab, in Startup selection, click Normal startup, and then click OK. The domain controller restarts normally. This procedure will disconnect your remote session. To restart a domain controller in DSRM remotely by using the command line 1. Connect to the remote domain controller that is running in normal mode: a. On the Start menu, click All Programs, click Accessories, and then click Remote Desktop Connection. b. In Computer, type the name of the domain controller that you want to restart, and then click Connect. c. In the Windows Security dialog box, provide credentials for a domain administrator, and then click OK. d. When you are connected, log on to the domain controller as a domain administrator. 2. Open a command prompt. At the command prompt, type the following command, and then press ENTER:
bcdedit /set safeboot dsrepair

3. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 -r

The domain controller restarts in DSRM. When the domain controller restarts, your Remote Desktop Connection is dropped. 4. Wait for a period of time that is adequate for the remote domain controller to restart, and then open Remote Desktop Connection. 5. The domain controller name should still be showing in Computer. If it is not, select it in the list, and then click Connect. 6. In the Windows Security dialog box, click Use another account. 7. In User name, type the following: MachineName\Administrator Where MachineName is the name of the domain controller.

291

8. In Password, type the DSRM password, and then click OK. 9. At the logon screen of the remote domain controller, click Switch User, and then click Other User. 10. Type MachineName\Administrator, and then press ENTER. 11. Perform procedures in DSRM. 12. When you have finished performing procedures in DSRM, restart the domain controller normally: a. In DSRM, open a command prompt, type the following command, and then press ENTER:
bcdedit /deletevalue safeboot

b. At the command prompt, type the following command, and then press ENTER:
shutdown -t 0 –r

The domain controller restarts normally. This procedure will disconnect your remote session.
Value Description

bcdedit /set safeboot dsrepair shutdown –t 0 -r bcdedit /deletevalue safeboot

Configures the boot process to start in DSRM. Shuts down the server and restarts it. Returns the boot process to the previous setting.

See Also
Enable Remote Desktop Create a Remote Desktop Connection Restart the Domain Controller in Directory Services Restore Mode Locally

Restore AD DS from Backup (Nonauthoritative Restore)
Nonauthoritative restore from backup restores Active Directory Domain Services (AD DS) from its current state to the previous state of a backup. Use this procedure before you perform an authoritative restore procedure to recover objects that were deleted after the time of the backup. To restore AD DS from backup, use a system state or critical-volumes backup. To restore AD DS from backup, you must restart the domain controller in Directory Services Restore Mode (DSRM).

292

Note If you are logging on to a read-only domain controller (RODC) locally or remotely, do not use a domain administrative account. Use only the delegated RODC administrator account. For more information about access to RODCs, see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). Be sure that you know the name and location of the version of the backup that you are restoring. Backup files are named for the date and time of the backup. When you restore the backup, the version must be stated in the form MM/DD/YYYY-HH:MM (month/day/year-hour:minute), which specifies the name of backup that you want to restore. The Wbadmin.exe command-line tool does not require that you provide the target for the recovery. By specifying the backup version that you want to recover, the command proceeds to recover to the source location of the backup version that you specify. Note The systemstaterecovery command in Wbadmin.exe causes a nonauthoritative restore of SYSVOL by default (only updates to SYSVOL since the time of the backup are replicated to the recovery domain controller). If you want to restore SYSVOL authoritatively (all of SYSVOL is replicated from the recovery domain controller to other domain controllers in the domain), specify the –authsysvol option in the command. The Administrator password for DSRM is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. The server must be running in DSRM. To perform a nonauthoritative restore of AD DS 1. At the Windows logon screen, click Switch User, and then click Other User. 2. Type .\administrator as the user name, type the DSRM password for the server, and then press ENTER. 3. Open a Command Prompt. 4. At the command prompt, type the following command, and then press ENTER:
wbadmin get versions -backuptarget:<targetDrive>: -machine:<BackupComputerName>

Where: •
<targetDrive>:

is the location of the backup that you want to restore.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was made. 5. Identify the backup version that you want to restore. You must enter this backup version exactly in the next step. 6. At the command prompt, type the following command, and then press ENTER:
wbadmin start systemstaterecovery -version:<MM/DD/YYYY-HH:MM>

293

-backuptarget:<targetDrive>: -machine:<BackupComputerName> -quiet

Where: • •
<MM/DD/YYYY-HH:MM> <targetDrive>:

is the version of the backup that you want to restore.

is the volume that contains the backup.

• <BackupComputerName> is the name of the computer where you want to recover the backup. This parameter is useful when you have backed up multiple computers to the same location or you have renamed the computer since the backup was taken. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the restore process and then press Y to confirm that the replication engine for SYSVOL has not changed since you created the backup. After the recovery operation is complete, if you are not going to perform an authoritative restore of any restored objects, restart the server.

Additional references
• • • • • 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 Performing Authoritative Restore of Active Directory Objects

Verify AD DS restore
After you complete a restore of Active Directory Domain Services (AD DS), you can use this procedure to verify the restore. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify an Active Directory restorefrom backup 1. After the restore operation completes, restart the computer in Start Windows Normally mode. If you used Bcdedit.exe to configure startup in Directory Services Restore Mode (DSRM), see Restart the Domain Controller in Directory Services Restore Mode Remotely or Restart the Domain Controller in Directory Services Restore Mode Locally for information about changing the configuration back to normal startup mode. 2. After you are able to log on to the system, perform the following verification steps: At a command prompt, use the repadmin /showsig command to verify that the invocation ID has changed. The invocation ID is the directory database globally unique identifier 294

(GUID), which the Directory System Agent (DSA) uses to identify the version of the database. The invocation ID changes during the Active Directory restore process to ensure the consistency of the replication process. Verify that the previous entry appears in the retired signatures list. At a command prompt, use the repadmin /showrepl command to verify that there are no replication errors and all directory partitions are replicating properly with the required replication partners. You can determine the replication partners by selecting the NTDS Settings object for the restored server in Active Directory Sites and Services. At a command prompt, use the net share command to verify that the NETLOGON and SYSVOL shares appear. At a command prompt, use the dcdiag command to verify success of all tests on the domain controller. Use Active Directory Users and Computers to verify that the deleted objects that you wanted to recover from the backup are restored. If you have a Volume Shadow Copy Service (VSS) snapshot of the database, you can use the Active Directory database mounting tool (Dsamain.exe) to mount the database and view it through Active Directory Users and Computers to compare the objects. For information about the Active Directory database mounting tool, see the Step-by-Step Guide for Using the Active Directory Database Mounting Tool in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=103333).

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. 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 domain controllers. 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 decide 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. We recommend that, before you install the operating system, you format the entire system disk, which removes all information on the system disk. Ensure that any important or relevant data is moved or backed up before you format the disk.

295

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 Dcdiag.exe Dcpromo.exe

To complete this task, perform the following procedures: 1. 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 from the name of the failed domain controller, in addition to cleaning up server metadata perform the following procedure: Delete a Server Object from a Site 2. Install Windows Server 2008. A fresh installation of Windows Server 2008 is assumed. Prepare for installation of the operating system by partitioning or reformatting the hard disk drive, if necessary. Note This guide does not provide information about installing Windows Server 2008. For information about installing Windows Server 2008, see Installing Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=111104). 3. Verify DNS Registration and TCP/IP Connectivity 4. Verify the Availability of the Operations Masters 5. Install an Additional Domain Controller by Using the Windows Interface During the installation process, replication occurs, which ensures that the domain controller has an accurate and up-to-date copy of Active Directory Domain Services (AD DS). 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.

296

6. After you install AD DS, see Verifying Active Directory Installation and perform procedures for verification of the installation.

Clean Up Server Metadata
Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS). You perform metadata cleanup on a domain controller in the domain of the domain controller that you forcibly removed. Metadata cleanup removes data from AD DS that identifies a domain controller to the replication system. Metadata cleanup also removes File Replication Service (FRS) and Distributed File System (DFS) Replication connections and attempts to transfer or seize any operations master (also known as flexible single master operations or FSMO) roles that the retired domain controller holds. These additional processes are performed automatically. You can use this procedure to clean up server metadata for a domain controller from which you have forcibly removed AD DS. On domain controllers that are running Windows Server 2008, you can use Active Directory Users and Computers to clean up server metadata. In this procedure, deleting the computer object in the Domain Controllers organizational unit (OU) initiates the cleanup process, which proceeds automatically. You can also perform metadata cleanup by using Ntdsutil.exe, a command-line tool that is installed automatically on all domain controllers. You can perform this procedure on a domain controller that is running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008. For information about performing metadata cleanup on domain controllers that are running earlier versions of Windows Server, see “Clean up server metadata” in the Windows Server 2003 Operations Guide (http://go.microsoft.com/fwlink/?LinkId=104231). You can also use a script to clean up server metadata on most Windows operating systems. For information about using this script, see Remove Active Directory Domain Controller Metadata (http://go.microsoft.com/fwlink/?LinkID=123599). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To clean up server metadata by using Active Directory Users and Computers 1. Open Active Directory Users and Computers: On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers. 2. If you have identified replication partners in preparation for this procedure, and if you are not connected to a replication partner of the removed domain controller whose metadata you are cleaning up, right-click Active Directory Users and Computers <DomainControllerName>, and then click Change Domain Controller. Click the name of the domain controller from which you want to remove the metadata, and then click OK. 3. Expand the domain of the domain controller that you forcibly removed, and then click 297

Domain Controllers. 4. In the details pane, right-click the computer object of the domain controller whose metadata you want to clean up, and then click Delete. 5. In the Active Directory Domain Services dialog box, click Yes to confirm the computer object deletion. 6. In the Deleting Domain Controller dialog box, select This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO), and then click Delete. 7. If the domain controller is a global catalog server, in the Delete Domain Controller dialog box, click Yes to continue with the deletion. 8. If the domain controller currently holds one or more operations master (also known as flexible single master operations or FSMO) roles, click OK to move the role or roles to the domain controller that is shown. You cannot change this domain controller. If you want to move the role to a different domain controller, you must move the role after you complete the server metadata cleanup procedure. To clean up server metadata by using Ntdsutil 1. Open a command prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
ntdsutil

3. At the ntdsutil: prompt, type the following command, and then press ENTER:
metadata cleanup

4. At the metadata ENTER: Or

cleanup:

prompt, type the following command, and then press

remove selected server <ServerName>

remove selected server <ServerName1> on <ServerName2>

298

Value

Description

ntdsutil: metadata cleanup remove selected server <ServerName> or <ServerName1>

Initiates removal of objects that refer to a decommissioned domain controller. Removes objects for a specified, decommissioned domain controller from a specified server. 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. If you specify only one server name, the objects are removed from the current domain controller. Specifies removing server metadata on <ServerName2>, the Domain Name System (DNS) name of the domain controller to which you want to connect. If you have identified replication partners in preparation for this procedure, specify a domain controller that is a replication partner of the removed domain controller.

on <ServerName2>

5. In Server Remove Configuration Dialog, review the information and warning, and then click Yes to remove the server object and metadata. At this point, Ntdsutil confirms that the domain controller was removed successfully. If you receive an error message that indicates that the object cannot be found, the domain controller might have been removed earlier. 6. At the metadata
cleanup:

and ntdsutil: prompts, type quit, and then press ENTER.

7. To confirm removal of the domain controller: Open Active Directory Users and Computers. In the domain of the removed domain controller, click Domain Controllers. In the details pane, an object for the domain controller that you removed should not appear. Open Active Directory Sites and Services. Navigate to the Servers container and confirm that the server object for the domain controller that you removed does not contain an NTDS Settings object. If no child objects appear below the server object, you can delete the server object. If a child object appears, do not delete the server object because another application is using the object.

See Also
Delete a Server Object from a Site

299

Delete a Server Object from a Site
When you remove a domain controller from service by uninstalling Active Directory Domain Services (AD DS), the domain controller object is removed from the domain directory partition automatically. You can check this deletion by looking in the Domain Controllers container in the Active Directory Users and Computers snap-in. The server object, which represents the domain controller in the configuration directory partition, can have child objects and is therefore not removed automatically. When no child objects are visible below the server object in Active Directory Sites and Services, you can use this procedure to remove the server object. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To delete a server object from a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, 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 object appears below the server object you want to delete, either replication on the domain controller on which you are viewing the configuration container has not occurred or the server whose server object you are removing has not been properly decommissioned. If a child object other than NTDS Settings appears below the server object that you want to delete, another application has published the object. You must contact an administrator for the application and determine the appropriate action to remove the child object. 4. Click Yes to confirm your choice.

See Also
Decommissioning a Domain Controller Forcing the Removal of a Domain Controller

300

Verify DNS Registration and TCP/IP Connectivity
You can use the Dcdiag command-line tests in this procedure to verify that a server can successfully connect to domain controllers in the same site or in the enterprise and to verify that Domain Name System (DNS) is functioning. By default, all Dcdiag tests verify TCP/IP connectivity for both IP version 4 (IPv4) and IP version 6 (IPv6). Note Dcdiag is installed with Active Directory Domain Services (AD DS) by default. To perform this test on a server that is not a domain controller, you must install Dcdiag. For information about installing Dcdiag, see Installing Remote Server Administration Tools for AD DS. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify DNS registration and TCP/IP connectivity 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:dns

Note For a more detailed response from this command, add /v to the end of the command. If the test fails, do not attempt any additional steps until you determine and fix the problem that prevents proper DNS functionality.

Verify the Availability of the Operations Masters
You can use this procedure to verify that the domain controllers that hold the operations master (also known as flexible single master operations or FSMO) roles can be located and that they are online and responding. You can use the tests in this procedure before you install Active Directory Domain Services (AD DS) as well as afterward. However, if you perform this procedure before you install AD DS, you must do the following: 301

• First, use Server Manager to add the Active Directory Domain Services server role. This part of the installation procedure installs the Dcdiag.exe command line tool. Perform this procedure after you add the server role but before you run Dcpromo.exe. • Use the /s command option to indicate the name of an existing domain controller in the domain of the new domain controller. This domain controller is required to verify the ability of the server to connect to operations master role holders in the domain and forest. You do not have to use the /s option if you perform the test in this procedure after you install AD DS. The test automatically runs on the local domain controller where you are performing the test. The commands in this procedure show the /s option. If you are performing this test after you install AD DS, 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. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify the availability of the operations masters 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command to ensure that the operations masters can be located, and then press ENTER:
dcdiag /s:<DomainControllerName> /test:knowsofroleholders /v

where <DomainControllerName> is the name of an existing 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. 3. Type the following command to ensure that the operations masters are functioning properly and available on the network, and then press ENTER:
dcdiag /s:<DomainControllerName> /test:fsmocheck

where <DomainControllerName> 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 as well as other important servers, such as global catalog servers and time servers. Near the bottom of your screen, a message confirms that the test succeeded. If these tests fail, do not attempt any additional steps until you fix the problem that prevents the location of operations masters and you can verify that they are functioning properly.

302

Install an Additional Domain Controller by Using the Windows Interface
You can use this procedure to add the Active Directory Domain Services (AD DS) server role to a server to create a domain controller in an existing domain. You can complete this procedure by using the Windows graphical user interface (GUI). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To install an additional domain controller by using the Windows interface 1. Click Start, and then click Server Manager. 2. In Roles Summary, click Add Roles. 3. Review the information on the Before You Begin page, and then click Next. 4. On the Select Server Roles page, click Active Directory Domain Services, and then click Next. 5. Review the information on the Active Directory Domain Services page, and then click Next. 6. On the Confirm Installation Selections page, click Install. 7. On the Installation Results page, click Close this wizard and launch the Active Directory Domain Services Installation Wizard (dcpromo.exe). 8. On the Welcome to the Active Directory Domain Services Installation Wizard page, click Next. You can click Use advanced mode installation to see additional installation options. Specifically, click Use advanced mode installation if you want to install from media or identify the source domain controller for Active Directory replication. 9. On the Operating System Compatibility page, review the warning about the default security settings for Windows Server 2008 domain controllers, and then click Next. 10. On the Choose a Deployment Configuration page, click Existing forest, click Add a domain controller to an existing domain, and then click Next. 11. On the Network Credentials page, type the name of any existing domain in the forest where you plan to install the additional domain controller. Under Specify the account credentials to use to perform the installation, click My current logged on credentials or click Alternate credentials, and then click Set. In the Windows Security dialog box, provide the user name and password for an account that can install the additional domain controller. To install an additional domain controller, you must be a member of the Enterprise Admins group or the Domain Admins group. When you are finished providing credentials, click Next. 12. On the Select a Domain page, select the domain of the new domain controller, and then click Next. 303

13. On the Select a Site page, select a site from the list or select the option to install the domain controller in the site that corresponds to its IP address, and then click Next. 14. On the Additional Domain Controller Options page, make the following selections, and then click Next: • DNS server: This option is selected by default so that your domain controller can function as a DNS server. If you do not want the domain controller to be a DNS server, clear this option. Note If you select the option to make this domain controller a DNS server, you might receive a message that indicates that a DNS delegation for the DNS server could not be created and that you should manually create a DNS delegation to the DNS server to ensure reliable name resolution. If you are installing an additional domain controller in either the forest root domain or a tree root domain, you do not have to create the DNS delegation. In this case, click Yes, and disregard the message. • Global Catalog: This option is selected by default. It adds the global catalog, readonly directory partitions to the domain controller, and it enables global catalog search functionality. • Read-only domain controller. This option is not selected by default. It makes the additional domain controller a read-only domain controller (RODC). 15. If you selected Use advanced mode installation on the Welcome page, the Install from Media page appears. You can provide the location of installation media to be used to create the domain controller and configure AD DS, or you can have all source replication occur over the network. Note that some data will be replicated over the network even if you install from media. For information about using this method to install the domain controller, see Installing an Additional Domain Controller by Using IFM. 16. If you selected Use advanced mode installation on the Welcome page, the Source Domain Controller page appears. Click Let the wizard choose an appropriate domain controller or click Use this specific domain controller to specify a domain controller that you want to provide as a source for replication to create the new domain controller, and then click Next. If you do not choose to install from media, all data will be replicated from this source domain controller. 17. On the Location for Database, Log Files, and SYSVOL page, type or browse to the volume and folder locations for the database file, the directory service log files, and the SYSVOL files, and then click Next. Windows Server Backup backs up the directory service by volume. For backup and recovery efficiency, store these files on separate volumes that do not contain applications or other nondirectory files. 18. On the Directory Services Restore Mode Administrator Password page, type and confirm the restore mode password, and then click Next. This password must be used to start AD DS in Directory Services Restore Mode (DSRM) for tasks that must be performed 304

offline. 19. On the Summary page, review your selections. Click Back to change any selections, if necessary. To save the settings that you have selected to an answer file that you can use to automate subsequent Active Directory operations, click Export settings. Type the name for your answer file, and then click Save. When you are sure that your selections are accurate, click Next to install AD DS. Note If you are installing an additional domain controller in a child domain and you are using child domain credentials, the Windows Security dialog box appears because access is denied in the parent domain to update the DNS delegation in the parent zone. In this case, click the other user icon and provide administrator credentials for the parent domain, and then click OK. 20. On the Completing the Active Directory Domain Services Installation Wizard page, click Finish. 21. You can select Reboot on completion to have the server restart automatically, or you can restart the server to complete the installation of AD DS when you are prompted to do so.

See Also
Preparing for Active Directory Installation Verifying Active Directory Installation

Verifying Active Directory Installation
There are several verification tasks that you can perform on a computer on which Active Directory Domain Services (AD DS) has been newly installed. Successfully completing the requirements of each verification task will provide a strong indication of a healthy, operational domain controller. The individual procedures in this task are provided so that you can test specific criteria to determine the health of an Active Directory installation. To thoroughly test the domain controller for all directory service issues, you can run the dcdiag /v command. The output of this command provides detailed information about the conditions on the domain controller. For information about using the Dcdiag.exe command-line tool, see Dcdiag (http://go.microsoft.com/fwlink/?LinkId=104689). Task requirements The following tools are recommended to perform the procedures for this task: • • • Active Directory Sites and Services DNS Manager Event Viewer 305

• •

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 Check that the new domain controller is located in the correct site so that the new domain controller can locate replication partners and become part of the replication topology. 3. Move a Server Object to a New Site If you have performed an unattended installation and the domain controller was not placed in the site that you expected, you can move the server object to the correct site. 4. Configure DNS Server Forwarders 5. Complete all procedures for the Verifying DNS Configuration task. 6. Check the Status of the SYSVOL and Netlogon Shares 7. Verify DNS Registration and TCP/IP Connectivity 8. Verify a Domain Computer Account for a New Domain Controller 9. Verify Active Directory Replication 10. Verify the Availability of the Operations Masters

Administering Intersite Replication
This guide provides information about administering intersite replication of Active Directory objects in the Windows Server 2008 operating system. In this guide • • Introduction to Administering Intersite Replication Managing Intersite Replication

Introduction to Administering Intersite Replication
This guide explains how to administer intersite replication. These administration activities are part of the operations phase of the information technology (IT) life cycle. If you are not familiar with this guide, review the following sections of this introduction. A site object in Active Directory Domain Services (AD DS) represents a collection of IP subnets, usually constituting a physical local area network (LAN). Multiple sites are connected for replication by site link objects. Sites are used in AD DS to:

306

• Make it possible for clients to discover network resources (published shares, domain controllers, global catalog servers) 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 AD DS 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 AD DS. Managing large hub-and-spoke topology is beyond the scope of this documentation. For information about managing branch sites, see the Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).

Optimizing replication between sites
The efficiency of replication between sites is optimized by cost settings on site links that favor replication routes between specific sites. 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 (three) between any two domain controllers. Between sites, the KCC on the domain controller that has the intersite topology generator (ISTG) role creates the topology based on site link cost. Designing a simple replication topology is the best way to optimize replication. Adding sites and domains increases the processing that is required by the KCC. Before adding to the site topology, be sure to review the guidelines in Adding a New Site. For information about topology design, see Designing the Site Topology for Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/? LinkId=89026).

Effects of site link bridging
By default, all site links are bridged. When site links are bridged, replication is transitive between sites and the costs that are assigned to site links are cumulative; the lowest-cost route between sites that have more than one site link is the route that replication takes. By default, site link costs are equal, with a cost of 100 on each new site link. For this reason, with no changes to the default site link cost, a hub-and-spoke topology favors the replication route between the hub site and each branch site, rather than between branch sites. The cost to replicate to and from two branch sites is always higher than the cost to replicate to and from the hub site. Therefore, replication between branch sites occurs only if no domain controller for the domain is available in the hub site.

Effects of disabling site link bridging
If you disable the Bridge all site links setting in the properties of the IP container in Active Directory Sites and Services, the ability of the ISTG to create the topology on the basis of cost is disabled. In addition, Distributed File System (DFS) cannot compute the cost matrix for its 307

site-costing functionality. Therefore, if you disable site link bridging and you are using File Replication Service (FRS) to replicate DFS replicas, which include the SYSVOL share, the DFS site-costing ability is also disabled. Note DFS Replication, which is available in domains that are at the Windows Server 2008 domain functional level, uses the replication topology that is defined by the administrator, which is independent of Active Directory site costing. If you turn off site link bridging, you must create site link bridges manually. For information about using manual site link bridges, see Creating a Site Link Bridge Design (http://go.microsoft.com/fwlink/?LinkId=122678). Note When you use FRS to replicate DFS replicas, you can maintain DFS site-costing functionality with Bridge all site links turned off. When the forest functional level is at least Windows Server 2003 or Windows Server 2003 interim and the ISTG in a site is running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008, you can use a site option to turn off automatic site link bridging for KCC operation without hampering the ability of DFS to use Intersite Messaging to calculate the cost matrix. This site option is set when you run the command repadmin /siteoptions W2K3_BRIDGES_REQUIRED. For more information about the effects of disabling site link bridging, see How Active Directory Replication Topology Works (http://go.microsoft.com/fwlink/?LinkId=93526). Do not disable Bridge all site links unless you are deploying a branch office environment. For information about branch office deployments, see “RODC Placement Considerations” in Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).

Optimizing domain controller location
Two new Group Policy settings are available on domain controllers that are running Windows Server 2008: Try Next Closest Site and Force Rediscovery Interval. These settings help Windows Vista and Windows Server 2008 clients in the domain to locate domain controllers in the next closest site if no domain controller in their own site is available. These settings improve domain controller discovery by controlling how the domain controller locator (DC Locator) process operates.

Finding the next closest site
By default, when a client requests a domain controller, the DC Locator process locates a domain controller in the site of the client. If no domain controller is available in the site, DC Locator returns any domain controller in the domain. If the domain controller is located in another branch site instead of the hub site, communication with the domain controller might be significantly slow. The Try Next Closest Site Group Policy setting in the Default Domain Policy can improve the location of domain controllers by clients that are running Windows Server 2008 or Windows Vista. 308

The Try Next Closest Site Group Policy setting uses site link cost values to determine the next closest site to the site of the client. Try Next Closest Site can affect how you configure site link costs because it affects the order in which domain controllers are located. For enterprises that have many hub sites and branch offices, you can significantly reduce Active Directory traffic on the network by ensuring that clients fail over to the next closest hub site when they cannot find a domain controller in the closest hub site. For more information, see Enabling Clients to Locate the Next Closest Domain Controller (http://go.microsoft.com/fwlink/?LinkId=120711).

Forcing domain controller rediscovery
In addition to finding a domain controller in the next closest site, a new Group Policy setting in Windows Server 2008 ensures that a client that is running Windows Vista or Windows Server 2008 finds a new domain controller that might be introduced since the last domain controller location. On domain controllers that are running Windows Server 2008, the Force Rediscovery Interval Group Policy setting forces a new domain controller location every 12 hours (43200 seconds) by default. You can change the time limit for rediscovery by enabling the setting and specifying a new time in seconds. By default, clients cache the last domain controller that was returned by DC Locator. On clients that are running Windows XP or Windows Server 2003, even if the domain controller that was last located is in a distant site, DC Locator continues to return the cached domain controller on each subsequent request. The cache is updated only if the cached domain controller is unavailable or the client restarts. For domain clients that are running Windows XP and Windows Server 2003, a hotfix is available that makes the registry setting available for this Group Policy setting. For information about downloading and using this hotfix, see article ID 939252 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=122681).

Improving the logon experience in branch sites
Branch sites often contain only a single domain controller that might not be a global catalog server. Perhaps replication of global catalog updates is considered to be prohibitive as a result of poor or unreliable bandwidth between the branch site and the nearest hub site. When the global catalog is required for domain logon and there is no global catalog server in the site, the domain controller must contact a global catalog server in another site. The global catalog is required when a domain user logs on interactively to a domain under the following conditions: • The user's domain has a domain functional level of Windows 2000 native, Windows Server 2003, or Windows Server 2008. In these cases, the user might belong to a universal group whose object is stored in a different domain. Only the global catalog stores universal group memberships for all domains in the forest. • The user’s logon name is a user principal name (UPN), which has the format sAMAccountName@DNSDomainName. In this case, the Domain Name System (DNS) domain

309

suffix is not necessarily the user’s domain and the identity of the user’s domain must be retrieved from a global catalog server. In Windows Server 2008, the best solution to this branch site scenario is to deploy a read-only domain controller (RODC) that is a global catalog server. In this case, although the global catalog must be replicated to the site, access to universal group memberships is always local and logon experience is consistent. In addition, RODCs provide more security against compromise than regular domain controllers because they are not writable. For information about deploying RODCs that are global catalog servers, see Planning and Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840). As an alternative to deploying the global catalog in the branch site, you can enable Universal Group Membership Caching, which means that the domain controller contacts the global catalog server only once for each user and that it caches all universal group memberships, rather than having to retrieve them at each logon. For more information about Universal Group Membership Caching, see How the Global Catalog Works (http://go.microsoft.com/fwlink/?LinkId=107063). For information about using Universal Group Membership Caching, see Enabling Universal Group Membership Caching in a Site.

See Also
Managing Intersite Replication

Managing Intersite Replication
This section includes the following tasks for managing intersite replication: • • • • • • • • Adding a New Site Linking Sites for Replication Changing Site Link Properties Enabling Clients to Locate the Next Closest Domain Controller Moving a Domain Controller to a Different Site Enabling Universal Group Membership Caching in a Site Forcing Replication Removing a Site

Adding a New Site
Design teams or network architects might want to add site objects in Active Directory Domain Services (AD DS) as part of ongoing deployment. Although you typically create subnets to accommodate all address ranges in the network, you do not have to create sites for every location. Generally, sites are required for those locations that have domain controllers or other servers that run applications, such as Distributed File System (DFS), that depend on site topology. 310

When a site is needed, 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 IP addresses is added to the network, create a subnet object in AD DS to correspond to the range of IP addresses. When you use Active Directory Sites and Services to create a new subnet object, you are required to associate the subnet with a site object. You can either associate the subnet with an existing site or create a new site first and then create the subnet and associate it with the new site. If a domain client has an IP address that does not map to a site, the client might be connected to a domain controller that is potentially far away from the client, causing slow responses for the client. Note When a domain client that has an IP address in a subnet that is not defined in AD DS connects to a domain controller, NETLOGON Event ID 5807 is generated in the System event log. The event indicates that clients have connected to the domain controller with IP addresses that do not map to a site. The text in the event provides instructions for determining the names and IP addresses of the client computers by searching the Netlogon.log file. Task requirements The following 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 a Site Associate an Existing Subnet Object with a 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 a Site from a Site Link

Create a Site Object and Add it to an Existing Site Link
To create a new site in your forest, you must create a site object in Active Directory Domain Services (AD DS) and then add the site object to a site link. You can use this procedure to create a site object and add it to an existing site link. Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review 311

details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create a site object and add it to an existing site link 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. Right-click the Sites container, and then click New Site. 3. In Name, type the name of the site. 4. In Link Name, click a site link for this site, and then click OK. 5. In Active Directory Domain Services, read the information, and then click OK.

See Also
Create a Subnet Object or Objects and Associate them with a Site Moving a Domain Controller to a Different Site

Create a Subnet Object or Objects and Associate them with a Site
If you create a new site or if you enlarge a new site, you can use this procedure to create a subnet object or objects and associate them with the site in Active Directory Domain Services (AD DS). You can assign the appropriate network address to the subnet object so that it represents a range of TCP/IP addresses. To accomplish this procedure, you must have the following information: • • The site with which the subnet is to be associated. The IP version 4 (IPv4) or IP version 6 (IPv6) subnet prefix.

Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create a subnet object or objects and associate them with a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand the Sites container, right-click Subnets, and then click New Subnet. 3. In New Object - Subnet, in Prefix, type the IPv4 or IPv6 subnet prefix for the subnet. 4. In Select a site object for this prefix, click the site to be associated with the subnet, and then click OK.

312

Associate an Existing Subnet Object with a Site
You can use this procedure to associate an existing subnet object with a site. A subnet object identifies a range of IP addresses that map respective computers to the site with which the subnet is associated in Active Directory Domain Services (AD DS). Associate an existing subnet with a site under the following conditions: • When you are removing the site to which the subnet is currently associated • When you have temporarily associated the subnet with a different site and you want to associate the subnet with its permanent site Membership in Enterprise Admins in the forest or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To associate an existing subnet object with a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, 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 Site, click the site to associate the subnet, and then click OK.

Create a Site Link Object and Add the Appropriate Sites
You can use this procedure to create a site link object and add the appropriate sites to it. When your network grows, you might add a site or sites in Active Directory Domain Services (AD DS) that you want to link to another site or sites for replication. If there is no existing site link to connect a site to the site with which its domain controllers replicate, use this procedure to create a site link object in the IP container in AD DS, and add the appropriate sites to the link. To link sites for replication, create a site link object in the container for the intersite transport that will replicate the site, and then add the sites to it. Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

313

To create a site link object 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. Expand Sites, and then expand Inter-Site Transports. 3. Right-click IP, and then click New Site Link. 4. In Name, type a name for the site link. 5. In Sites not in this site link, 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 hold down the CTRL key to click a second site that is not adjacent in the list. 6. After you select all the sites that you want to add to the site link, click Add, and then click OK.

Remove a Site from a Site Link
If you change the site topology and want to remove a site from a site link, or if you are removing a site from the enterprise, you can use this procedure to remove a site from a site link in Active Directory Domain Services (AD DS). If you are adding a site to a different site link, you must first remove the site from its current site link. Membership in Enterprise Admins in the forest or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To remove a site from a site link 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, 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 Sites in this site link, click the site that you want to remove from the site link. 5. Click Remove, and then click OK.

Linking Sites for Replication
Linking sites is required for Active Directory replication to occur between sites. Plan your site topology and then implement the plan by creating sites and site links. For information about 314

planning your site topology, see Designing the Site Topology for Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/?LinkId=89026).

Creating site links
To link sites for Active Directory replication, create a site link object in the IP transport container in Active Directory Domain Services (AD DS) 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.

Selecting bridgehead servers
By default, the intersite topology generator (ISTG) selects bridgehead servers in a site automatically. We recommend that you allow the ISTG to perform bridgehead server selection. However, if you want to ensure that only certain domain controllers in the sites you are linking perform replication between sites, you can designate preferred bridgehead servers in the site. Note 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. Use the following guidelines when you select bridgehead servers: • Selecting preferred bridgehead servers limits the bridgehead servers that the Knowledge Consistency Checker (KCC) can use to those bridgehead servers 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 bridgehead servers as possible and you must select them for all domains that must be replicated to a different site. • If a site contains a global catalog server, select the global catalog server as a preferred bridgehead server. When you use preferred bridgehead servers, the following problems can occur: • 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 select a non-global-catalog server but a global catalog server currently exists in the site, or the global catalog is subsequently added to another domain controller in the site, the global catalog server cannot receive updates of read-only domain directory partitions for any domain that does not have a selected bridgehead server in the site. 315

Task requirements The following 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

3. If you are designating servers that will perform intersite replication, you can Designate a Server as a Preferred Bridgehead Server.

Create a Site Link Object and Add the Appropriate Sites
You can use this procedure to create a site link object and add the appropriate sites to it. When your network grows, you might add a site or sites in Active Directory Domain Services (AD DS) that you want to link to another site or sites for replication. If there is no existing site link to connect a site to the site with which its domain controllers replicate, use this procedure to create a site link object in the IP container in AD DS, and add the appropriate sites to the link. To link sites for replication, create a site link object in the container for the intersite transport that will replicate the site, and then add the sites to it. Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create a site link object 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. Expand Sites, and then expand Inter-Site Transports. 3. Right-click IP, and then click New Site Link. 4. In Name, type a name for the site link. 5. In Sites not in this site link, 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 hold down the CTRL key to click a second site that is not adjacent in the list. 6. After you select all the sites that you want to add to the site link, click Add, and then click OK.

316

Determine the ISTG Role Owner for a Site
The Intersite Topology Generator (ISTG) is the domain controller in each site that is responsible for generating the intersite topology. If you want to regenerate the intersite topology, you must determine the identity of the ISTG role owner in a site. You can use this procedure to view the NTDS Site Settings object properties and determine the ISTG role owner for the site. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the ISTG role owner for a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, click the site object whose ISTG role owner 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
You can use this procedure to generate the intersite replication topology on the intersite topology generator (ISTG). The Knowledge Consistency Checker (KCC) generates the Active Directory replication topology on every domain controller. The KCC runs by default every 15 minutes. You can force the KCC to run on any domain controller. The topology that is generated depends on the domain controller on which you run the command. 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. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

317

To generate the replication topology on the ISTG 1. Determine the server that holds the ISTG role for the site. 2. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 3. In the console tree, expand Sites, and then expand the site that contains the ISTG on which you want to run the KCC. 4. Expand Servers, and then click the Server object for the ISTG. 5. In the details pane, right-click NTDS Settings, click All Tasks, and then click Check Replication Topology. 6. In the Check Replication Topology message box, click OK.

Designate a Server as a Preferred Bridgehead Server
You can use this procedure to designate a server as a preferred bridgehead server. If you want to manually select the domain controllers that can replicate between sites, use the server object properties to designate a preferred bridgehead server on the IP transport. If you use preferred bridgehead servers, make sure to designate more than one preferred bridgehead server in the site and designate at least one preferred bridgehead server for each domain that is replicated to another site. Before you perform this procedure, review the information about the effects of selecting bridgehead servers in Linking Sites for Replication. Membership in Enterprise Admins or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To designate a preferred bridgehead server 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then expand the site of the preferred bridgehead server. 3. Expand Servers to display the list of domain controllers that are currently configured for that site. 4. Right-click the server that you want to designate as a preferred bridgehead server, and then click Properties. 5. In Transports available for inter-site data transfer, click IP. 6. Click Add, and then click OK. 318

Changing Site Link Properties
To control which sites replicate directly with each other, and when, you can use the cost, schedule, and interval properties on the site link object in Active Directory Domain Services (AD DS). For information about how to design the site topology, see Designing the Site Topology for Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/?LinkId=89026). 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. The default setting is every 180 minutes. • Cost: The relative priority of the link. The default setting is 100. Lower relative cost increases the priority of the link over other, higher-cost links. Consult your design documentation for information about the values to set for site link properties. Task requirements The following 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. To generate the intersite topology, perform the following procedures: a. Determine the ISTG Role Owner for a Site b. Generate the Replication Topology on the ISTG

Configure the Site Link Schedule to Identify Times During Which Intersite Replication Can Occur
If you need to change the schedule for Active Directory replication between sites, configure the site link object in Active Directory Domain Services (AD DS). Use the properties on the site link object to define when replication is allowed to occur between the bridgehead servers in the sites that are

319

assigned to the site link. You can use this procedure to configure the site link schedule. Obtain the site link schedule from your design team. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure the site link schedule 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites and Inter-Site Transports, and then click IP. 3. In the details pane, right-click the site link object that 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 (that is, be 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
Bridgehead servers initiate intersite replication by polling their replication partners. You configure the polling schedule on the site link object in Active Directory Domain Services (AD DS). You can use this procedure and 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. Note Intersite connection objects also have a schedule; they inherit their schedule and interval from the site link object. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure the site link interval 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 320

2. In the console tree, expand Sites and Inter-Site Transports, and then click IP. 3. In the details pane, right-click the site link object that you want to configure, and then click Properties. 4. In Replicate every _____ minutes, 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
The cost setting on a site link object determines the likelihood that replication occurs over a particular route between two site. Relication routes with the lowest cumulative cost are preferred. You can use this procedure to configure replication cost on the site link object in Active Directory Domain Services (AD DS). When you create or modify site links, use the site link object properties to configure the relative cost of using the site link. To perform this procedure, you must have site topology information that includes the cost values for the sight links that you want to manage. The cost that you set in this procedure must be determined relative to existing or planned costs of other site links. You can use any range of numbers; only their relative values (higher or lower) are important. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure the site link cost 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites and Inter-Site Transports, and then click IP. 3. In the details pane, right-click the site link object that you want to configure, and then click Properties. 4. In Cost, specify the number for the comparative cost of using the site link, and then click OK.

Determine the ISTG Role Owner for a Site
The Intersite Topology Generator (ISTG) is the domain controller in each site that is responsible for generating the intersite topology. If you want to regenerate the intersite topology, you must

321

determine the identity of the ISTG role owner in a site. You can use this procedure to view the NTDS Site Settings object properties and determine the ISTG role owner for the site. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the ISTG role owner for a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, click the site object whose ISTG role owner 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
You can use this procedure to generate the intersite replication topology on the intersite topology generator (ISTG). The Knowledge Consistency Checker (KCC) generates the Active Directory replication topology on every domain controller. The KCC runs by default every 15 minutes. You can force the KCC to run on any domain controller. The topology that is generated depends on the domain controller on which you run the command. 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. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To generate the replication topology on the ISTG 1. Determine the server that holds the ISTG role for the site. 2. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 3. In the console tree, expand Sites, and then expand the site that contains the ISTG on 322

which you want to run the KCC. 4. Expand Servers, and then click the Server object for the ISTG. 5. In the details pane, right-click NTDS Settings, click All Tasks, and then click Check Replication Topology. 6. In the Check Replication Topology message box, click OK.

Enabling Clients to Locate the Next Closest Domain Controller
In a Windows Server 2008 domain, you can make it possible for client computers that run Windows Vista or Windows Server 2008 to locate domain controllers more efficiently by enabling the Try Next Closest Site Group Policy setting. This setting improves the Domain Controller Locator (DC Locator) by helping to streamline network traffic, especially in large enterprises that have many branch offices and sites. This new setting can affect how you configure site link costs because it affects the order in which domain controllers are located. For enterprises that have many hub sites and branch offices, you can significantly reduce Active Directory traffic on the network by ensuring that clients fail over to the next closest hub site when they cannot find a domain controller in the closest hub site. As a general best practice, you should simplify your site topology and site link costs as much as possible if you enable the Try Next Closest Site setting. In enterprises with many hub sites, this can simplify any plans that you make for handling situations in which Windows Vista or Windows Server 2008 clients in one site need to fail over to a domain controller in another site. By default, the Try Next Closest Site setting is not enabled. When the setting is not enabled, DC Locator uses the following algorithm to locate a domain controller: • Try to find a domain controller in the same site. • If no domain controller is available in the same site, try to find any domain controller in the domain. Note This is the same algorithm that DC Locator used in previous versions of Active Directory. For more information, see How DNS Support for Active Directory Works (http://go.microsoft.com/fwlink/?LinkId=108587). If you enable the Try Next Closest Site setting, DC Locator uses the following algorithm to locate a domain controller: • Try to find a domain controller in the same site. • If no domain controller is available in the same site, try to find a domain controller in the next closest site. A site is closer if it has a lower site-link cost than another site with a higher site-link cost. 323

• If no domain controller is available in the next closest site, try to find any domain controller in the domain. By default, DC Locator does not consider any site that contains a read-only domain controller (RODC) when it determines the next closest site. For example, assume that a site topology has four sites with the site link values in the following illustration. In this example, all the domain controllers are writable domain controllers.

When the Try Next Closest Site Group Policy setting is enabled in this example, if a Windows Vista or Windows Server 2008 client computer in Site_B tries to locate a domain controller, it first tries to find a domain controller in its own Site_B. If none is available in Site_B, it tries to find a domain controller in Site_A. If the setting is not enabled, the Windows Vista or Windows Server 2008 client tries to find a domain controller in Site_A, Site_C, or Site_D if no domain controller is available in Site_B. To apply the Try Next Closest Site setting, you can create a Group Policy object (GPO) and link it to the appropriate object for your organization, or you can modify the Default Domain Policy to have it affect all Windows Vista and Windows Server 2008 clients in the domain. For more information about how to set the Try Next Closest Site setting, see Enable Clients to Locate a Domain Controller in the Next Closest Site.

324

Enable Clients to Locate a Domain Controller in the Next Closest Site
You can modify the Default Domain Policy to enable Windows Vista and Windows Server 2008 clients in the domain to locate domain controllers in the next closest site if no domain controller in their own site or the closest site is available. Membership Enterprise Admins in the forest or Domain Admins in the domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To enable clients to locate a domain controller in the next closest site 1. Click Start, click Administrative Tools, and then click Group Policy Management. 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. 3. Double-click Forest:forest_name, double-click Domains, and then double-click domain_name. 4. Right-click Default Domain Policy, and then click Edit. 5. In Group Policy Management Editor, in the console tree, go to Computer Configuration/Policies/Administrative Templates/System/Netlogon/DC Locator DNS Records. 6. In the details pane, double-click Try Next Closest Site, click Enabled, and then click OK. As an option, you can create the following registry entry to affect the Domain Locator (DC Locator) behavior for an individual computer that runs Windows Vista or Windows Server 2008. However, using a domain-wide Group Policy object (GPO) is recommended instead because the behavior will be more consistent. Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\Try Next Closest Site If the registry entry DWORD value is 1, DC Locator will try to find the domain controller in the next closest site if it cannot find a domain controller in the client's site. If the value is 0, DC Locator will find any domain controller if it cannot find a domain controller in the client's site.

325

Moving a Domain Controller to a Different Site
When you install Active Directory Domain Services (AD DS) on a server running Windows Server 2008, you can select the site for the domain controller. If you do not make this selection, the domain controller is placed into the site that its IP address maps to. If you change the IP address or the subnet-to-site association of a domain controller after AD DS 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 Netlogon service on the domain controller registers Domain Name System (DNS) service (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 configured statically, 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 wide area network (WAN) link to locate resources, rather than locating resources in its own site. Before you move 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 Windows Internet Name Service (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.

DNS settings
If the domain controller is a DNS server, you must update the IP address in any DNS delegations or forwarders that reference the IP address. With dynamic update enabled, DNS updates host (A), host (AAAA), and name server (NS) resource records automatically. However, you must update delegations and forwarders as follows: • Delegations: Determine whether the parent DNS zone of any zone that is hosted by this DNS server contains a delegation to this DNS server. If the parent DNS zone does contain a delegation to this DNS server, update the IP address in the name server (NS) resource record in the parent domain DNS zone that points to this DNS server. • Forwarders: Determine whether the server acts as a forwarder for any DNS servers. If a DNS server uses this server as a forwarder, change the name server (NS) resource record for the forwarder on that DNS server. 326

Preferred bridgehead server status
Before you move any server object, check the server object to see whether it is acting as a preferred bridgehead server for the site. This condition has implications for the Intersite Topology Generator (ISTG) in both sites, as follows: • In the 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). • In the 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 that host 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 The following is required to perform the procedures for this task: • • • Network Connections DNS snap-in Active Directory Sites and Services

To complete this task, perform the following procedures in order: 1. Change the Static IP Address of a Domain Controller 2. Update the IP Address for a DNS Delegation 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

327

procedure on a DNS server in the DNS parent domain. If you are following recommended practices, the parent domain is the forest root domain. 3. Update the IP Address for a DNS Forwarder If the DNS server is configured as a forwarder for any other DNS server, use this procedure to update the IP address in all forwarders. 4. Verify That an IP Address Maps to a Subnet and Determine the Site Association 5. To determine whether the server is a preferred bridgehead server, you can check a single server or you can view the entire preferred bridgehead server list: • • Determine Whether a Server is a Preferred Bridgehead Server View the List of All Preferred Bridgehead Servers

6. Configure a Server to Not Be a Preferred Bridgehead Server 7. Move a Server Object to a New Site

Change the Static IP Address of a Domain Controller
If you move a domain controller to a different site, you must change the IP address of the domain controller to an IP address that maps to a subnet that is associated with the site. To change an IP address, you use the TCP/IP client settings in the properties of the network connection. You can use this procedure to change all appropriate values in the TCP/IP client settings on a domain controller, including preferred and alternate DNS servers, as well as Windows Internet Name Service (WINS) servers (if appropriate). Obtain these values from your design team. If you change the static IP address of a domain controller, make sure that the IP address is included in the respective Dynamic Host Configuration Protocol (DHCP) scope. You must also verify that DNS resource records are updated on the DNS server that the domain controller references as the preferred DNS server in TCP/IP settings. In DNS, verify the values of the following resource records. If they have not updated automatically, update the IP address in these resource records: • • Host (A) or host (AAAA) resource records Name Server (NS) resource records

Use the DNS snap-in to update the following DNS values that apply to this domain controller: • On the Forwarders tab in the properties of a DNS server, update the IP address on DNS servers for which this domain controller is designated as a forwarder. • Use the procedure Update the IP Address for a DNS Delegation for all delegations to this domain controller. • On the Zone Transfers tab in the properties of a forward lookup zone, update the IP address for any primary or seconday DNS zone transfers to this domain controller.

328

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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. Click Start, point to Administrative Tools, click Server Manager, and then click View Network Connections. 3. In the Network Connections dialog box, right-click the appropriate connection, and then click Properties. 4. In the Connection Properties dialog box, double-click Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol Version 6 (TCP/IPv6). 5. In IP address, type the new address. 6. In Subnet mask, type the new subnet mask if it has changed. 7. In Default gateway, type the new default gateway. 8. In Preferred DNS server, type the address of the Domain Name System (DNS) server that this computer contacts if it has changed. 9. In Alternate DNS server, 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 have 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.

Update the IP Address for a DNS Delegation
If you change the IP address of a domain controller that is a Domain Name System (DNS) server, you must update the IP address in the delegation for the DNS server in the DNS zone for the parent domain. You can use this procedure to update the IP address of a delegation for a domain controller that is also a DNS server. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

329

To update the IP address for a DNS delegation 1. Open the DNS snap-in: On the Start menu, point to Administrative Tools, and then click DNS. 2. In the console tree, if you are connected to a DNS server that hosts the parent zone, go to step 4. If you are not connected to a DNS server that hosts the parent zone, rightclick DNS and then click Connect to DNS Server. 3. Click The following computer, type the name of the DNS server that hosts the parent zone, and then click OK. 4. In the console tree, double-click the server node for a DNS server that hosts the parent zone, double-click Forward Lookup Zones, and then double-click the parent zone. 5. In the console tree, right-click the delegated zone of the DNS server whose IP address has changed, and then click Properties. 6. On the Name Servers tab, click the DNS server whose IP address has changed, and then click Edit. 7. In the IP Address list, click the address, and then type changes as necessary. 8. Click OK twice.

Update the IP Address for a DNS Forwarder
If you change the IP address of a domain controller that is a Domain Name System (DNS) server, if the server is designated as a forwarder for another DNS server you must update the IP address in the forwarder name server (NS) record. You can use this procedure to update the IP address of a forwarder for a domain controller that is also a DNS server. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To update the IP address for a DNS forwarder 1. Open the DNS snap-in: On the Start menu, point to Administrative Tools, and then click DNS. 2. In the console tree, if you are connected to the DNS server that uses the forwarder whose IP address you want to change, go to step 4. If you are not connected to the DNS server that uses the forwarder, right-click DNS and then click Connect to DNS Server. 3. Click The following computer, type the name of the DNS server that uses the forwarder, and then click OK. 4. In the console tree, click the node for the DNS server that uses the forwarder whose IP address has changed. 5. In the details pane, double-click Forwarders. 330

6. In the IP Address list, click the address that you want to change, and then click Edit. 7. In the IP Address list, click the address, and then type changes as necessary. 8. Click OK twice.

Verify That an IP Address Maps to a Subnet and Determine the Site Association
You can use this procedure to determine the site to which you want to add a server object before you install Active Directory Domain Services (AD DS). You can also use this procedure to verify the site after you install AD DS or before you move a server object. To be associated with a site, the IP address of a domain controller must map to a subnet object that is defined in AD DS. 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 AD DS. When you know the subnet address, you can locate the subnet object and determine the site to which the subnet is associated. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify that an IP address maps to a subnet and to determine the site association 1. Log on locally or open a Remote Desktop connection to the server for which you want to check the IP address. 2. In Server Manager, click View Network Connections. 3. Right-click the connection that represents the connection the server or domain controller uses to attach to the network, and then click Properties. 4. In the Connection Properties dialog box, double-click Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol Version 6 (TCP/IPv6). 5. Use an IP subnet calculator and the values in IP address and Subnet mask to calculate the subnet address, and then click OK twice. 6. Open the Active Directory Sites and Services snap-in: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 7. Expand the Sites container, and then click the Subnets container. 8. In the Name column in the details pane, find the subnet object that matches the subnet address for the server or domain controller. 9. In the Site column, note the site to which the IP subnet address is associated. 331

If the site that appears in the Site column is not the appropriate site, contact a site administrator and find out whether the IP address is incorrect or whether you should move the server object to the site that is indicated by the subnet-to-site association.

See Also
Move a Server Object to a New Site

Determine Whether a Server is a Preferred Bridgehead Server
You can designate preferred bridgehead servers to always perform intersite replication. If you are moving a server to a different site, you must make sure that the server is not a preferred bridgehead server. If it is a preferred bridgehead server, you must configure it to not be a preferred bridgehead server before you move the server object. You can use this procedure to view the server object properties in Active Directory Domain Services (AD DS) and determine the bridgehead server status of the server. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine whether a server is a preferred bridgehead server 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. Expand Sites, and then expand the site of the server whose bridgehead server status you want determine. 3. Expand the Servers node to display the list of domain controllers that are currently configured for that site. 4. Right-click the server whose status you want to check, and then click Properties. 5. If IP appears in the list that marks this server as a bridgehead server for the IP transport, the server is a preferred bridgehead server.

See Also
Configure a Server to Not Be a Preferred Bridgehead Server View the List of All Preferred Bridgehead Servers

332

View the List of All Preferred Bridgehead Servers
When you manage preferred bridgehead servers or when you move a server object, you might want to identify the domain controllers that are preferred bridgehead servers. 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. A back-link attribute on the IP transport object shows the entire list. If you want to check all servers for preferred bridgehead server status, rather than a single server, you can use this procedure to view the list of all preferred bridgehead servers. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To view the list of preferred bridgehead servers 1. Click Start, point to Administrative Tools, and then click Active Directory Sites and Services. 2. Expand the Sites container and the Inter-Site Transports container. 3. Right-click the IP container, and then click Properties. 4. Click Filter, and then, under Show read-only attributes, click Backlinks. 5. In Attributes, double-click bridgeheadServerListBL. 6. 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.

See Also
Determine Whether a Server is a Preferred Bridgehead Server Configure a Server to Not Be a Preferred Bridgehead Server

Configure a Server to Not Be 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. If you want to remove a server from the list so that it is not a designated preferred bridgehead server, you can use this procedure to open the server object properties and remove the server from the IP transport. Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review

333

details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure the server to not be a preferred bridgehead server 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then expand the site of the preferred bridgehead server. 3. Expand the Servers container to display the list of domain controllers that are currently configured for that site. 4. Right-click the server that 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.

See Also
View the List of All Preferred Bridgehead Servers

Move a Server Object to a New Site
When you move a server object in Active Directory Domain Services (AD DS), the Active Directory Sites and Services snap-in does not require that the IP address of the server maps to the site to which you are moving the server object. If the IP address does not map to a subnet that is associated with the site to which you move it, the server might be forced to communicate over a potentially slow wide area network (WAN) link to locate resources rather than locating resources in its own site. Before you move the server object, verify that the IP address maps to the target site. You can use this procedure to move a server object to a new site. Membership in Enterprise Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To move a server object to a new site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites and the site in which the server object resides. 3. Expand Servers to display the domain controllers that are currently configured for that site. 4. Right-click the server object that you want to move, and then click Move. 5. In Site Name, click the destination site, and then click OK. 6. Expand the site object to which you moved the server, and then expand the Servers 334

container. 7. Verify that an object for the server that 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 Domain Name System (DNS). Wait an hour, and then open Event Viewer and connect to the domain controller whose server object you moved. Review the System log for NETLOGON errors regarding registration of service (SRV) resource records in DNS that have occurred within the last hour. The absence of errors indicates that the Net Logon service has updated DNS with sitespecific service (SRV) resource records. NETLOGON Event ID 5774 indicates that the dynamic registration of DNS resource records has failed. If this error occurs, contact a supervisor and pursue DNS troubleshooting.

See Also
Verify That an IP Address Maps to a Subnet and Determine the Site Association

Enabling Universal Group Membership Caching in a Site
In a multidomain forest, when a user logs on to a domain, a global catalog server must be contacted to determine the universal group memberships of the user. A universal group can contain users from other domains, and it can be applied to access control lists (ACLs) on objects in all domains in the forest. Therefore, universal group memberships must be ascertained at domain logon so that the user has appropriate access in the domain and in other domains during the logon session. Only global catalog servers store the memberships of all universal groups in the forest. If a global catalog server is not available in the site when a user logs on to a domain, the domain controller must contact a global catalog server in another site. In multidomain forests where remote sites do not have a global catalog server, the need to contact a global catalog server over a potentially slow wide are network (WAN) connection can be problematic and a user can potentially be unable to log on to the domain if a global catalog server is not available. You can enable Universal Group Membership Caching on domain controllers that are running Windows Server 2008 so that when the domain controller contacts a global catalog server for the user’s initial domain logon, the domain controller retrieves universal group memberships for the user. On subsequent logon requests by the same user, the domain controller uses cached universal group memberships and does not have to contact a global catalog server. Task requirements The following tool is required to perform the procedures for this task: • • Active Directory Sites and Services Enable Universal Group Membership Caching in a Site 335 To complete this task, perform the following procedure:

Enable Universal Group Membership Caching in a Site
In a branch site that has no global catalog server and in a forest that has multiple domains, you can use this procedure to enable Universal Group Membership Caching on a domain controller in the site so that a global catalog server does not have to be contacted across a wide area network (WAN) link for every initial user logon. You enable this setting on the NTDS Site Settings object for the site in Active Directory Domain Services (AD DS), and you can specify the site of a global catalog server to contact when the cache must be updated. In most cases, the closest global catalog server is located in the hub site. You can use this procedure to enable Universal Group Membership Caching in a site. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To enable Universal Group Membership Caching in a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then click the site in which you want to enable Universal Group Membership Caching. 3. In the details pane, right-click the NTDS Site Settings object, and then click Properties. 4. Under Universal Group Membership Caching, select Enable Universal Group Membership Caching. 5. In the Refresh cache from list, click the site that you want the domain controller to contact when the Universal Group membership cache must be updated, and then click OK.

Forcing Replication
When you need updates to be replicated sooner than the intersite replication schedule allows, or when replication between sites is impossible because of configuration errors, you can force replication to and from domain controllers. You can use the following two methods of forcing replication: • Force replication of all directory partition updates from one server to another server over a connection • Force replication of configuration directory partition updates from one server to another server

336

Forcing replication of all directory updates over a connection
If you want to replicate certain updates, such as a significant addition of new passwords or user accounts, to another domain controller in the domain, you can use the Replicate now option in the Active Directory Sites and Services snap-in to force replication of all directory partitions over a connection object that represents inbound replication from a specific domain controller. A connection object for a server object that represents a domain controller identifies the replication partner from which the domain controller receives replication. If the changes are made on one domain controller, you can select the connection from that domain controller and force replication to its replication partner. You can also use the Repadmin.exe command-line tool to replication changes from a server to one or more other servers or to all servers.

Forcing replication of configuration updates
Active Directory replication uses a pull model, in which one domain controller requests changes from another domain controller. For this reason, connection objects always represent one-way, inbound replication from a source server to a destination server. All objects that are required for replication are contained in the configuration directory partition, which is replicated to every domain controller in the forest. If a site link is deleted inadvertently, the domain controllers in the respective sites drop connection objects that represent servers in any site to which the domain controller’s site is no longer linked. The only way for these connection objects to be recreated is for a new site link to be created and for domain controllers in each site in the site link to recreate the connection objects. However, the change to the configuration directory partition (the new site link) cannot be replicated from the site where the change occurs to the other site because the domain controllers in the other site have dropped their inbound connection objects from servers in the site where the site link has been recreated. The Replicate now option does not fix the problem because the ability to use Replicate now depends on the existence of a from-server connection object. On writable domain controllers running Windows Server 2003, the only way to resolve this issue is to create the new site link object twice, once on a domain controller in each site. When the domain controller has a site link, the Knowledge Consistency Checker (KCC) on the domain controller can then create connection objects from servers in the other site. On writable domain controllers running Windows Server 2008, a new option is available that you can use to force replication of only the configuration directory partition to a domain controller in another site, even though a connection object from a server in the site does not exist in the configuration directory partition. In this case, you can recreate the site link in one site and force replication of this configuration change to a domain controller in the other site. When replication of the new site link object is received on the domain controller in the other site, that domain controller can then create new connection objects from servers in the other sites in the site link. This functionality is particularly useful if the only domain controller in a site is a read-only domain controller (RODC). In this case, you cannot recreate the site link on a domain controller in both 337

sites because you cannot write to the RODC. When you recreate the site link in the hub site and then force replication of the configuration directory partition to the site of the RODC, you enable the RODC to create connection objects from replication partners in the hub site. 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. Force Replication Between Domain Controllers 2. Update a Server with Configuration Changes 3. Synchronize Replication with All Partners 4. Verify Successful Replication to a Domain Controller

Force Replication Between Domain Controllers
You can use this procedure to force Active Directory replication to occur between two domain controllers on a one-time basis when you want changes to be replicated from the server that received the changes to a server in another site sooner than the site link schedule allows. As an alternative, you can synchronize replication with all replication partners. Membership in Enterprise Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To force replication over a connection 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then expand the site to which you want to force replication from the updated server. 3. Expand the Servers container to display the list of servers that are currently configured for that site. 4. Expand the server objects and click their NTDS Settings objects to display their connection objects in the details pane. Find a server that has a connection object from the server on which you made the updates. 5. Click NTDS Settings below the server object. In the details pane, right-click the connection object whose From Server is the domain controller that has the updates that you want to replicate, and then click Replicate Now. 6. When the Replicate Now message box appears, review the information, and then click OK. 338

See Also
Synchronize Replication with All Partners

Update a Server with Configuration Changes
On a domain controller that is running Windows Server 2008, you can use this procedure to force replication of configuration changes to a domain controller that is not receiving replication as a result of configuration errors. This procedure is particularly useful for updating a read-only domain controller (RODC) in a branch site with configuration changes from a hub site, for example, when a site link object has been inadvertently deleted. You can complete this procedure by using either the Windows interface or the Repadmin command-line tool. Membership in Enterprise Admins in the forest or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To use the Windows interface to update a server with configuration changes 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then expand the site of the domain controller that you want to receive configuration updates. 3. Expand the Servers container to display the list of servers that are currently configured for that site. 4. Double-click the server object that requires the configuration updates that you want to replicate. 5. Right-click NTDS Settings below the server object, and then click Replicate configuration to the selected DC. 6. In the Replicate Now message box, click OK. To use Repadmin to update a server with configuration changes 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl <ServerName>

Where <ServerName> is the name of the domain controller that has the configuration changes that you want to replicate. The /showrepl switch provides the globally unique identifier (GUID) information that you need for step 6. 339

3. Click the Command Prompt menu in the title bar, click Edit, and then click Mark. 4. Use the cursor to select the value in DSA
object GUID.

5. Click the Command Prompt menu in the title bar, and then click Copy. Use the Paste command on the Command Prompt menu to paste this value for the <SourceDomainControllerGUID> parameter in the next step. 6. At the command prompt, type the following command, and then press ENTER:
repadmin /sync <ConfigurationDistinguishedName> <DestinationServerName> <SourceDomainControllerGUID>

Value

Description

/sync <ConfigurationDistinguishedName>

Synchronizes replication of the specified directory partition between the specified domain controllers The configuration directory partition distinguished name: CN=Configuration,DC=ForestRootDomainName The name of the domain controller that is to receive the configuration updates, for example, DC3B. The Directory System Agent (DSA) GUID of the domain controller that is forcing replication.

<DestinationServerName>

<SourceDomainControllerGUID>

Synchronize Replication with All Partners
You can use this procedure to synchronize replication with all replication partners of a domain controller. Membership in Enterprise Admins in the forest or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To synchronize replication with all partners 1. At a command prompt, type the following command, and then press ENTER:
repadmin /syncall <DomainControllerName> /e /d /A /P /q

340

Value

Description

repadmin /syncall <DomainControllerName>

Synchronizes a specified domain controller with all replication partners. The Domain Name System (DNS) name of the domain controller on which you want to synchronize replication with all partners. Enterprise; includes partners in all sites. Identifies servers by their distinguished names 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.

341

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. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify successful replication to a domain controller 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl <servername> /u:<domainname>\<username> /pw:*

Note The user credential parameters (/u:<domainname>\<username> /pw:*) are not required for the domain of the user if the user has opened the Command Prompt as an administrator with Domain Admins credentials or is logged on to the domain controller as a member of Domain Admins or equivalent. However, if you run the command for a domain controller in a different domain in the same Command Prompt session, you must provide credentials for an account in that domain.

342

Value

Description

repadmin /showrepl

Displays the replication status for the last time that the domain controller that is named in <servername> attempted inbound replication of Active Directory partitions. The name of the destination domain controller. Specifies the domain name and user name, separated by a backslash, for a user who has permissions to perform operations in AD DS. 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.) The name of an administrative account in that domain. Specifies the domain password for the user named in <username>. * provides a Password: prompt when you press ENTER.

<servername> /u:

<domainname>

<username> /pw:*

3. At the Password: prompt, 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 Microsoft Excel 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 creates this spreadsheet and sets column headings for improved readability.

343

To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv >showrepl.csv

3. Open Excel. 4. Click the Office button, 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. • Or • To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top Row. 8. Select the entire spreadsheet. On the Data tab, click Filter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the filter down arrow, point to Text Filters, and then click Custom Filter. 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 11 for the Last Failure Time column, but use the value does not equal, and then 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 (http://go.microsoft.com/fwlink/?LinkID=93582): • • • The last successful intersite replication was before the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful. To hide the column, right-click the column, and then click Hide.

344

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 you delete the site, you must remove each domain controller from the site either by removing domain controller completely or by moving it to a new location: • To remove the domain controller completely, remove Active Directory Domain Services (AD DS) from the server and then delete the server object from the site in AD DS. • To retain the domain controller in a different location, move the domain controller itself to the new site and then move the server object to the respective site in AD DS. Before you remove a server object from a site, check the NTDS Settings object of the server to see if the server has a manual connection object from any server in another site. If a manual connection object exists, check the source server in the other site for a corresponding manual connection object from the server that you are removing. The Knowledge Consistency Checker (KCC) does not remove manual connection objects automatically. Therefore, if you leave a manually created connection object on a server and then remove the source server for the connection, the inability of the destination server to replicate from its source replication partner will cause replication errors to be generated. If a manual connection object exists in the NTDS Settings object of a server in another site, and if the server that you are removing is the source (“replicate from”) server for the connection, delete that manual connection object on the destination server to avoid unnecessary replication errors after you have removed the server object. 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 Microsoft Operations Manager (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 that 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 that use 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. 345

Site link objects: • If the site that you are removing is added to a site link that contains only two sites, delete the site link object. • If the site that you are removing is added to a site link that contains more than two sites, do not delete this site link object. Before you remove a site, consider the implications. If the site that 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. Delete a manual Connection object 2. Determine Whether a Server Object Has Child Objects 3. Delete a Server Object from a Site 4. Delete a Site Link object 5. Associate an Existing Subnet Object with a Site 6. Delete a Site object 7. 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

Delete a Manual Connection Object
If you are removing a server object that has a manual connection object, you must remove the corresponding connection object on the destination domain controller. The Knowledge Consistency Checker (KCC) does not remove manual connection objects automatically. If the source (“replicate from”) server in the connection is being removed and you no longer need a manual connection object on the destination server, delete the connection object from the destination server. You can use this procedure to delete a manual connection object. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To delete a manual connection object 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative 346

Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites, and then expand the site of the server whose manual connection object you want to delete. 3. Expand Servers, and then expand the server object whose manual connection object you want to delete. 4. Click the NTDS Settings object of the server object, and then, in the details pane, view the Name column to find a connection object that has a name other than <automatically generated>. 5. Usually, a manual connection object is named for the source server. To be sure, rightclick the connection object and then, in Replicate from, note the server name in the Server box. This is the source server from which this connection transfers replication updates to the destination server whose NTDS Settings object you have selected. 6. If you no longer want the destination server to explicitly use this server as its replication source, right-click the manual connection object, and then click Delete.

Determine Whether a Server Object Has Child Objects
After Active Directory Domain Services (AD DS) is properly installed on a domain controller, the server object for the domain controller has a child NTDS Settings object. Other applications that are running on domain controllers can also publish child objects. When you remove AD DS from a server, the NTDS Settings child object is removed automatically from the server object in the Servers container in Active Directory Sites and Services. Before you delete a server object from the Servers container for a site, verify that the server object has no child objects. The following conditions might result in the presence of a child object: • If an NTDS Settings object is present, it is possible that replication of the deletion has not reached the domain controller whose objects you are viewing. Check the presence of the object on another domain controller, or force replication from another domain controller in the domain. (See Force Replication Between Domain Controllers.) • If a child object other than NTDS Settings is present, another application has published the object and is using the server object. In this case, do not delete the server object. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure when you perform the procedure remotely by using Remote Server Administration Tools (RSAT). Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine whether a server object has child objects 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative 347

Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, expand the Sites container, and then 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 you remove a domain controller from service by uninstalling Active Directory Domain Services (AD DS), the domain controller object is removed from the domain directory partition automatically. You can check this deletion by looking in the Domain Controllers container in the Active Directory Users and Computers snap-in. The server object, which represents the domain controller in the configuration directory partition, can have child objects and is therefore not removed automatically. When no child objects are visible below the server object in Active Directory Sites and Services, you can use this procedure to remove the server object. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To delete a server object from a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, 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 object appears below the server object you want to delete, either replication on the domain controller on which you are viewing the configuration container has not occurred or the server whose server object you are removing has not been properly decommissioned. If a child object other than NTDS Settings appears below the server object that you want to delete, another application has published the object. You must contact an administrator for the application and determine the appropriate action to remove the child object. 4. Click Yes to confirm your choice. 348

See Also
Decommissioning a Domain Controller Forcing the Removal of a Domain Controller

Delete a Site Link object
If you are removing a site and you no longer need a site link, you can use this procedure to delete a site link object. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To delete a site link object 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites and Inter-Site Transports, and then click IP. 3. In the details pane, right-click the site link object that you want to delete, and then click Delete. 4. Click Yes to confirm your choice.

Associate an Existing Subnet Object with a Site
You can use this procedure to associate an existing subnet object with a site. A subnet object identifies a range of IP addresses that map respective computers to the site with which the subnet is associated in Active Directory Domain Services (AD DS). Associate an existing subnet with a site under the following conditions: • When you are removing the site to which the subnet is currently associated • When you have temporarily associated the subnet with a different site and you want to associate the subnet with its permanent site Membership in Enterprise Admins in the forest or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To associate an existing subnet object with a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative 349

Tools, and then click Active Directory Sites and Services. 2. In the console tree, 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 Site, click the site to associate the subnet, and then click OK.

Delete a Site object
You can use this procedure to delete a site object. Delete a site object only after you have removed all server objects from the site and you have reassociated the subnets with a different site. The Servers container is deleted when you delete the site. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To delete a site object 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, click the Sites container. 3. In the details pane, right-click the site that you want to delete, and then click Delete. 4. Click Yes to confirm your choice. 5. In the Active Directory message box, read the information, and then click Yes to delete the site and its servers container object.

See Also
Delete a Server Object from a Site Delete a Site Link object

Determine the ISTG Role Owner for a Site
The Intersite Topology Generator (ISTG) is the domain controller in each site that is responsible for generating the intersite topology. If you want to regenerate the intersite topology, you must determine the identity of the ISTG role owner in a site. You can use this procedure to view the NTDS Site Settings object properties and determine the ISTG role owner for the site.

350

Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the ISTG role owner for a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, click the site object whose ISTG role owner 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
You can use this procedure to generate the intersite replication topology on the intersite topology generator (ISTG). The Knowledge Consistency Checker (KCC) generates the Active Directory replication topology on every domain controller. The KCC runs by default every 15 minutes. You can force the KCC to run on any domain controller. The topology that is generated depends on the domain controller on which you run the command. 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. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To generate the replication topology on the ISTG 1. Determine the server that holds the ISTG role for the site. 2. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 3. In the console tree, expand Sites, and then expand the site that contains the ISTG on which you want to run the KCC. 351

4. Expand Servers, and then click the Server object for the ISTG. 5. In the details pane, right-click NTDS Settings, click All Tasks, and then click Check Replication Topology. 6. In the Check Replication Topology message box, click OK.

Administering the Active Directory Database
This guide provides information about administering the Active Directory database in the Windows Server 2008 operating system. In this guide • • Introduction to Administering the Active Directory Database [lhsad]_ADDS_Ops_7 Managing the Active Directory Database

Introduction to Administering the Active Directory Database [lhsad]_ADDS_Ops_7
Active Directory Domain Services (AD DS) is stored in the Ntds.dit database file. In addition to this file, the directory service uses log files, which store transactions before they commit them to the database file. For best performance, store the log files and the database on separate hard drives. Before you perform any procedures that affect the directory database, be sure that you have a current system state or critical-volume backup. For information about backing up AD DS, see Backing Up Active Directory Domain Services.

Database management conditions
The Active Directory database is a self-maintained system. It requires no daily maintenance, other than regular backup, during ordinary operation. However, you may have to manage it if the following conditions occur: • Low disk space: move the files to a different location permanently, or replace the disk on which the database or log files are stored. • Pending or current hardware failure: upgrade or replace the disk on which the database or log files are stored. • A need to recover physical disk space: defragment the database after bulk deletion or removal of the global catalog.

352

Disk space monitoring recommendations
Monitor free disk space on the partition or partitions that store the directory database and logs. The following are the recommended parameters for free disk 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 20 percent of the combined Ntds.dit and log files sizes or 1 gigabyte (GB).

Database defragmentation
During ordinary operation, you will delete objects from AD DS. When you delete an object, free (unused) disk space is created in the database. On a regular basis, the database consolidates this free disk space through a process called online defragmentation. This disk space will be reused when new objects are added (without adding any size to the file itself). This automatic online defragmentation redistributes and retains free disk space for use by the database, but does not release the disk space to the file system. Therefore, the database size does not shrink, even though objects might be deleted. In cases in which the data decreases significantly, such as when the global catalog is removed from a domain controller, free disk space is not automatically returned to the file system. Although this condition does not affect database operation, it does result in large amounts of free disk space in the database. To decrease the size of the database file by returning free disk space from the database file to the file system, you can perform an offline defragmentation of the database. Whereas online defragmentation occurs automatically while AD DS is running, offline defragmentation requires taking the domain controller offline and using the Ntdsutil.exe commandline tool to perform the procedure.

Note NTFS disk compression is not supported for the database and log files.

Restartable AD DS
On domain controllers that are running Windows Server 2008, performing offline defragmentation and other database management tasks does not require a restart of the domain controller in Directory Services Restore Mode (DSRM). You can stop the AD DS service while you perform database management procedures. This feature, called restartable AD DS, eliminates the need to restart the domain controller when you perform certain database management tasks. Services that are running on the server that depend on AD DS to function shut down before AD DS shuts down. The following services stop when you stop AD DS: • • • DNS Server service File Replication Service (FRS) Kerberos Key Distribution Center (KDC) 353

• •

Intersite Messaging Distributed File System (DFS) Replication

Other services that are running on the server and that do not depend on AD DS to function, such as Dynamic Host Configuration Protocol (DHCP), remain available to satisfy client requests while AD DS is stopped. For information about restartable AD DS, see Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649).

See Also
Managing the Active Directory Database

Managing the Active Directory Database
This section includes the following tasks for managing the Active Directory database: • • Relocating the Active Directory Database Files Returning Unused Disk Space from the Active Directory Database to the File System

Relocating the Active Directory Database Files
Relocating Active Directory database files usually involves moving files to a temporary location while hardware updates are being performed and then moving the files to a permanent location. On domain controllers that are running versions of Windows 2000 Server and Windows Server 2003, moving database files requires restarting the domain controller in Directory Services Restore Mode (DSRM). Windows Server 2008 introduces restartable Active Directory Domain Services (AD DS), which you can use to perform database management tasks without restarting the domain controller in DSRM. Before you move database files, you must stop AD DS as a service. For information about restartable AD DS, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). 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, provide more disk space by taking one of the following actions:

354

• 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 you move files to a different partition, you must update the registry manually. 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 or critical-volume 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 after the move. Revise permissions to just the permissions that are required to protect the database files, if necessary. 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 Directory System Agent (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 following specified size, 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.

355

• Database file only: The size of the database file, plus 20 percent of the Ntds.dit file or 500 megabytes (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 gigabyte (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, net stop, net start dir xcopy Ntdsutil.exe Windows Server Backup 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. Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) (http://go.microsoft.com/fwlink/?LinkId=118357) 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 system state or criticalvolume backup before you move database files.

356

4. 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. 5. Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) (http://go.microsoft.com/fwlink/?LinkId=118357)

Determine the Database Size and Location Online
You can use this procedure to determine the size and location of the Active Directory database when Active Directory Domain Services (AD DS) is running in normal Windows mode on a domain controller that is connected to the network (that is, on a domain controller that is online). When you determine 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, Event ID 1646 in the Directory Service log also reports the size of the database file: “Total allocated hard disk space (megabytes):” As an alternative, you can determine the size of the database file by listing the contents of the directory that contains the files. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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 as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 357

2. Change directories to the directory that contains the files that you want to manage. 3. At the command prompt, type dir, and then press ENTER to examine the database size. In the following example command output, the Ntds.dit file and the log files are stored in the same directory. In the example, the files take up 58,761,256 bytes of disk space. This output is representative of a directory database to which few objects have been added. C:\Windows\NTDS>dir Volume in drive C has no label. Volume Serial Number is 003D-0E9E Directory of C:\Windows\NTDS 01/29/2008 11:04 AM 01/29/2008 11:04 AM 01/29/2008 10:29 AM 01/29/2008 10:29 AM 01/29/2008 10:29 AM 01/29/2008 10:29 AM 01/29/2008 10:29 AM 01/29/2008 10:29 AM 01/28/2008 02:54 PM 7 File(s) 2 Dir(s) <DIR> <DIR> . ..

8,192 edb.chk 10,485,760 edb.log 10,485,760 edb00001.log 10,485,760 edbres00001.jrs 10,485,760 edbres00002.jrs 14,696,488 ntds.dit 2,113,536 temp.edb

58,761,256 bytes 126,027,243,520 bytes free

See Also
Determine the Database Size and Location Offline

Determine the Database Size and Location Offline
You can use this procedure to determine the size and location of the Active Directory database when Active Directory Domain Services (AD DS) is offline. When you determine the database size and location offline, the size is reported in megabytes (MB). On domain controllers that are running Windows Server 2008, you can take AD DS offline by stopping the service. Otherwise, the domain controller must be started in Directory Services Restore Mode (DSRM). For information about stopping the AD DS service on domain controllers that are running Windows Server 2008, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/? LinkId=88649).

358

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 online, see Determine the Database Size and Location Online. If you have set garbage collection logging to report free disk space, Event ID 1646 in the Directory Service log also reports the size of the database file: “Total allocated hard disk space (megabytes):” As an alternative, you can determine the size of the database file by listing the contents of the directory that contains the files. Membership in Builtin Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the database size and location offline 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop ntds

Type Y to agree to stop additional services, and then press ENTER. 3. At the command prompt, type ntdsutil, and then press ENTER. 4. At the ntdsutil prompt, type activate
instance ntds,

and then press ENTER.

5. At the ntdsutil prompt, type files, and then press ENTER. 6. At the file maintenance prompt, type info, and then press ENTER. Make a note of the file sizes that appear. 7. At the file maintenance prompt, type quit, and then press ENTER. Type quit, and then press ENTER again to quit Ntdsutil.exe. 8. At the command prompt, type the following command, and then press ENTER:
net start ntds

See Also
Determine the Database Size and Location Online

Compare the Size of the Directory Database Files to the Volume Size
Before you move any Active Directory database files in response to low disk space, verify that no other files on the volume are responsible for the condition of low disk space. 359

You might have to relocate the database file, the log files, or both, if disk space on the volume on which they are stored becomes low. Before you move 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—compared 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. You can use this procedure to compare the size of the directory database files to the size of the volume. If Active Directory Domain Services (AD DS) is started when you are comparing the size of the directory database files and volume, membership in Domain Admins is the minimum required to complete this procedure. If AD DS is stopped, membership in Builtin Administrators is the minimum required to complete this procedure. If the domain controller is restarted in Directory Services Restore Mode (DSRM), the DSRM administrator password is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To compare the size of the directory database files to the volume size 1. On the Start menu, click Computer. 2. In the Folders list, click Computer. 3. In the details pane, locate the volume that has low disk space. Make a note of the value in the Total Size column for that volume. 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 values of Total Size (volume) and Size on disk (database files plus SYSVOL if SYSVOL is on the same volume). If the combined size of the relevant database files and SYSVOL files (if appropriate) is significantly smaller than the volume size, check the contents of the volume for other files. 8. If other files are present, move those files and then reassess the disk space on the volume.

Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin)
You can use this procedure to back up system state on a domain controller. Membership in Builtin Administrators or Backup Operators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and

360

group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. In addition, you must have write access to the target backup location. To perform a system state backup of a domain controller 1. Click Start, click Command Prompt, and then click Run as administrator. 2. If you are prompted, in the User Account Control dialog box, provide Backup Operator credentials, and then click OK. 3. At the command prompt, type the following command, and then press ENTER:
wbadmin start systemstatebackup -backuptarget:<targetDrive>: -quiet

Where <targetDrive> identifies the local volume or the letter of the physical disk drive to receive the backup. You cannot store a system state backup on a network shared drive. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the backup operation.

Additional considerations
Be aware of the following issues when you perform a system state backup: • To use Wbadmin.exe, you must install Windows Server Backup. For more information about installing Windows Server Backup, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkID=96495). • The target volume for a system state backup can be a local drive, but it cannot be any of the volumes that are included in the backup by default. To store the system state backup on a volume that is included in the backup, you must add the AllowSSBToAnyVolume registry entry to the server that you are backing up. There are also some prerequisites for storing system state backup on a volume that is included in the backup. For more information, see Known Issues for AD DS Backup and Recovery (http://go.microsoft.com/fwlink/? LinkID=117940).

Move the Directory Database and Log Files to a Local Drive
You can use this procedure to move Active Directory database and log files to a local drive. When you move the files to a folder on the local domain controller, you can move them permanently or temporarily. Move the files to a temporary destination if you need to reformat the original location, or move the files to a permanent location if you have additional disk space. If you reformat the original drive, use the same procedure to move the files back after the reformat is complete. Ntdsutil.exe updates the registry when you move files locally. Even if you are moving the files only temporarily, use Ntdsutil.exe so that the registry is always current.

361

If you do not have space on the local domain controller to move the files temporarily, you can copy files to a remote share. For information about copying files to a remote share, see Copy the Directory Database and Log Files to a Remote Share. On a domain controller that is running Windows Server 2008, you do not have to restart the domain controller in Directory Services Restore Mode (DSRM) to move database files. You can stop the Active Directory Domain Services (AD DS) service and then restart the service after you move the files to their permanent location. For information about restartable AD DS, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide on the Microsoft Web site at (http://go.microsoft.com/fwlink/?LinkId=88649). Membership in Builtin Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To move the directory database and log files to a local drive 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop ntds

Type Y to agree to stop additional services, and then press ENTER. 3. At the command prompt, change directories to the current location of the directory database file (Ntds.dit) or the log files, whichever you are moving. 4. Run the dir command, and make a note of the current size and location of the Ntds.dit file. 5. At the command prompt, type ntdsutil, and then press ENTER. 6. At the ntdsutil prompt, type activate 8. To move the database file, at the file commands: • •
instance ntds,

and then press ENTER.

7. At the ntdsutil prompt, type files, and then press ENTER.
maintenance:

prompt, use the following

To move the Ntds.dit file, type the following command, and then press ENTER: To move the log files, type the following command, and then press ENTER:

move db to<drive>:\<directory>

move logs to<drive>:\<directory>

where <drive>:\<directory> specifies the path to the new location. If the directory does not exist, 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". 9. After the move completes, at the file
maintenance:

prompt, type quit, and then press 362

ENTER. Type quit again, and then press ENTER to quit Ntdsutil.exe. 10. 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, check the size of the Ntds.dit file against the file size that you noted in step 4 to be sure that you are focused on the correct file. 11. If you are moving the database file or log files permanently, go to step 12. 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 3 through 9 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 13. 12. 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, 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 then click Advanced. Verify that the permissions are as follows: Administrators group has Allow Full Control. SYSTEM has Allow Full Control. The Include inheritable permissions from this object’s parent check box is cleared. No Deny permissions are selected. c. If the permissions in step 12b are in effect, go to step 13. If permissions other than the permissions described in step 12b are in effect, perform steps 12d through 12k. d. If Include inheritable permissions from this object’s parent is selected, click Edit, click to clear the setting, and then click OK. When you are prompted, click Copy to copy previously inherited permissions to this object. e. If Administrators or SYSTEM, or both, are not in the Name list, click OK, click Edit, and then click Add. f. In From this location, be sure that the name of the domain is selected. g. In Enter the object names to select, type System, if necessary, and then click OK. Repeat to add Administrators, if necessary, and then click OK. h. On the Security tab, click System, and then, in the Allow column, click Full Control. Repeat for Administrators. i. In the Group or user names 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. 363

j.

Click OK to close Properties.
instance ntds,

13. At the command prompt, type ntdsutil, and then press ENTER. 14. At the ntdsutil prompt, type activate 16. At the file
maintenance:

and then press ENTER.

15. At the ntdsutil prompt, type files, and then press ENTER. prompt, type integrity, and then press ENTER. If the integrity check fails, see If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup. 17. If the integrity check succeeds, type quit, and then press ENTER to quit the file maintenance prompt. Type quit again, and then press ENTER to quit Ntdsutil.exe. 18. At the command prompt, type the following command, and then press ENTER:
net start ntds

19. Open Event Viewer, and check the Directory Service log for errors. 20. If the following events are logged in the Directory Service log in Event Viewer when you restart AD DS, stop AD DS, and then resolve the event issues as follows: • Event ID 1046. “The Active Directory database engine caused an exception with the following parameters.” In this case, AD DS cannot recover from this error and you must restore AD DS from backup. • Event ID 1168. “Internal error: An Active Directory error has occurred.” In this case, information is missing from the registry and you must restore AD DS from backup.

See Also
If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup Copy the Directory Database and Log Files to a Remote Share Recovering Active Directory Domain Services

Copy the Directory Database and Log Files to a Remote Share
You can use this procedure to copy the Active Directory directory database and log files to a remote shared folder. 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 enough space to move the files locally, 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. Use this method only if the path to the files does not change.

364

Important When you relocate 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 the files that are necessary to restore the directory service are maintained. If you have enough space locally on the domain controller and you do not want to copy database files to a remote share, you can use Ntdsutil to move the files to a local folder. For information about moving the database files, see Move the Directory Database and Log Files to a Local Drive. On a domain controller that is running Windows Server 2008, you do not have to restart the domain controller in Directory Services Restore Mode (DSRM) to copy database files. You can stop the Active Directory Domain Services (AD DS) service and then restart the service after you copy the files to their permanent location. For information about restartable AD DS, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/? LinkId=88649). Membership in Builtin Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To copy the directory database and log files to a remote share and back to the local computer 1. Before you stop AD DS, prepare a shared directory on a remote server in the domain. Create separate subdirectories for the database files and log files. Allow access only to the Builtin Administrators group. 2. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 3. At the command prompt, type the following command, and then press ENTER:
net stop ntds

Type Y to agree to stop additional services, and then press ENTER. 4. At the command prompt, 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 4 for each directory. 5. Run the dir command, and make a note of the current size and location of the Ntds.dit file and the log files. 6. Establish a network connection to the shared folder. After you type the following command and press ENTER, you are prompted for the password for the specified account. Type the password, and then press ENTER.
net use <NetworkDrive>: \\<ServerName>\<SharedFolderName> /user:<domainName>\<userName> *

365

Value

Description

net use <NetworkDrive>: \\<ServerName>\<SharedFolderName>

Specifies the drive letter to use for connecting to the shared folder. The universal naming convention (UNC) name of the shared folder location, specifying the server that stores the shared folder and the name of the shared folder, separated by a backslash. Specifies the domain name and user name, separated by a backslash, for a user who has permissions to perform operations in AD DS. Provides a Type the password for \\<ServerName>\<SharedFolderName>: prompt when you press ENTER.

/user:<domainName>\<userName>

*

For example, if you shared the \TempCopy directory on the server named SERVER1, the following command maps network drive G: to the shared location and provides the domain and user name for user tonip5:
net use G: \\server1\tempcopy /user:contoso\tonip5 *

7. Use the xcopy command to copy the database files to the location that you established in step 6. Type the following command, and then press ENTER:
xcopy \<PathToDatabaseFiles> <NetworkDrive>:\<DatabaseSubdirectory>

This command copies the contents of the local folder for the database to the named subfolder in the remote shared folder. For example, the following command copies the database files from their location on the domain controller to the DB subdirectory on the mapped drive G:
xcopy \windows\ntds G:\DB

8. Repeat step 7 to copy the log files. For example, the following command copies the log files to the Logs subdirectory on the mapped drive G:
xcopy \windows\ntds\*.log G:\Logs

9. Change drives to the remote directory and run the dir command in each subdirectory to compare the file sizes to the file sizes that are listed in step 5. Use this step to ensure that you copy the correct set of files back to the local computer. 10. At this point, you can safely destroy data on the original local drive. 11. After the destination drive is prepared, re-establish a connection to the network drive as described in step 6, if necessary. 12. Use the method in step 7 to copy the database and log files from the remote shared folder back to the original location on the domain controller. 366

13. At the command prompt, type ntdsutil, and then press ENTER. 14. At the ntdsutil prompt, type activate 16. At the file
maintenance: instance ntds,

and then press ENTER.

15. At the ntdsutil prompt, type files, and then press ENTER. prompt, type integrity, and then press ENTER. If the integrity check fails, see If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup. 17. If the integrity check succeeds, type quit, and then press ENTER to quit the file maintenance: prompt. Type quit again, and then press ENTER to quit Ntdsutil.exe. 18. At the command prompt, type the following command, and then press ENTER:
net start ntds

19. Open Event Viewer, and check the Directory Service log for errors. 20. If the following events are logged in the Directory Service log in Event Viewer when AD DS restarts, resolve the events as follows: • Event ID 1046. “The Active Directory database engine caused an exception with the following parameters.” In this case, AD DS cannot recover from this error and you must restore AD DS from backup. • Event ID 1168. “Internal error: An Active Directory error has occurred.” In this case, information is missing from the registry and you must restore AD DS from backup.

See Also
If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup Move the Directory Database and Log Files to a Local Drive Recovering Active Directory Domain Services

Returning Unused Disk Space from the Active Directory Database to the File System
During ordinary operation, the free disk space in the Active Directory database file becomes fragmented. Each time garbage collection runs (every 12 hours, by default), free disk space is automatically defragmented online to optimize its use within the database file. The unused disk space is 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, when you remove the global catalog from a domain controller), or if the size of the database backup is significantly increased as a result of the amount of free disk space, use offline defragmentation to reduce the size of the Ntds.dit file. 367

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 that the database file uses 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. These events include Event IDs 700 and 701, which report when online defragmentation begins and ends, respectively. At level 1, higher-level events are logged as well. At level 1, Event ID 1646 is also reported, which indicates the amount of free space that is available in the database relative to 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. On domain controllers that are running Windows Server 2008, offline defragmentation does not require restarting the domain controller in Directory Services Restore Mode (DSRM), as is required on domain controllers that are running versions of Windows Server 2000 and Windows Server 2003. You can use a new feature in Windows Server 2008, restartable Active Directory Domain Services (AD DS), to stop the AD DS service. When the service is stopped, services that depend on AD DS shut down automatically. However, any other services that are running on the domain controller, such as Dynamic Host Configuration Protocol (DHCP), continue to run and respond to clients. For more information about restartable AD DS, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/? LinkId=88649). After offline defragmentation completes, perform a database integrity check. The integrity command in Ntdsutil.exe detects binary-level database corruption by reading every byte in the database file. This process ensures that the correct headers exist in the database itself and that all of the tables are functioning and consistent. Therefore, depending on 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 gigabytes (GB) per hour is considered to be typical. When you run the command, an online graph displays the percentage completed. If the database integrity check fails, you must perform semantic database analysis. Task requirements The following tools are required to perform the procedures for this task: • • • Regedit.exe Windows Server Backup Ntdsutil.exe

To complete this task, perform the following procedures: 1. Change the Garbage Collection Logging Level to 1 2. Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) (http://go.microsoft.com/fwlink/?LinkId=118357) 3. Compact the Directory DatabaseFfile (Offline Defragmentation) 368

As part of the offline defragmentation procedure, check directory database integrity. 4. If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup

Change the Garbage Collection Logging Level to 1
Garbage collection in Active Directory Domain Services (AD DS) is the process of removing deleted objects (tombstones) from the directory database. This process results in free disk space in the directory database. By default, this free space is not reported in Event Viewer. To see the amount of free disk space that can be made available to the file system by offline defragmentation, you can change the garbage collection logging level so that the disk space is reported in the Directory Service event log. After you change the logging level, 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. You can use this procedure to change the garbage collection logging level to 1 so that you can view Event ID 1646 in Event Viewer. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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 Recovery [lhsad_ADDS_Ops_5]_ADDS_Ops_5. 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\Diagnostics. 3. Double-click Garbage Collection. In the Value data box, type 1, and then click OK.

See Also
Compact the Directory DatabaseFfile (Offline Defragmentation)

369

Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin)
You can use this procedure to back up system state on a domain controller. Membership in Builtin Administrators or Backup Operators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. In addition, you must have write access to the target backup location. To perform a system state backup of a domain controller 1. Click Start, click Command Prompt, and then click Run as administrator. 2. If you are prompted, in the User Account Control dialog box, provide Backup Operator credentials, and then click OK. 3. At the command prompt, type the following command, and then press ENTER:
wbadmin start systemstatebackup -backuptarget:<targetDrive>: -quiet

Where <targetDrive> identifies the local volume or the letter of the physical disk drive to receive the backup. You cannot store a system state backup on a network shared drive. If you do not specify the -quiet parameter, you are prompted to press Y to proceed with the backup operation.

Additional considerations
Be aware of the following issues when you perform a system state backup: • To use Wbadmin.exe, you must install Windows Server Backup. For more information about installing Windows Server Backup, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkID=96495). • The target volume for a system state backup can be a local drive, but it cannot be any of the volumes that are included in the backup by default. To store the system state backup on a volume that is included in the backup, you must add the AllowSSBToAnyVolume registry entry to the server that you are backing up. There are also some prerequisites for storing system state backup on a volume that is included in the backup. For more information, see Known Issues for AD DS Backup and Recovery (http://go.microsoft.com/fwlink/? LinkID=117940).

370

Compact the Directory DatabaseFfile (Offline Defragmentation)
You can use this procedure to compact the Active Directory database offline. Offline defragmentation returns free disk space in the Active Directory database to the file system. 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 network-mapped drive. However, to avoid potential problems related to network issues, it is best to perform this procedure locally, if space allows. You can use locally attached external mass storage devices, such as Universal Serial Bus (USB), IEEE 1394, and Serial Advanced Technology Attachment (SATA), to provide additional disk space for defragmentation of the database. After you compact the file to the temporary location, copy the compacted Ntds.dit file back to the original location. If space allows, 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, Active Directory Domain Services (AD DS) must be offline. On domain controllers that are running Windows Server 2008, you can take AD DS offline by stopping the service. Otherwise, the domain controller must be started in Directory Services Restore Mode (DSRM). For information about stopping the AD DS service on domain controllers that are running Windows Server 2008, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). For information about performing this procedure in DSRM, see Compact the directory database file (offline defragmentation) (http://go.microsoft.com/fwlink/?LinkId=55393). Membership in Builtin Administrators, or equivalent, is the minimum required to complete this procedure. If you are compacting to the database to a remote location, you must have Read and Write permissions on the destination drive and the shared folder. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Disk space • Current database drive. Free space (on the drive that contains the Active Directory database file) equivalent of at least 15 percent of the current size of the database (Ntds.dit) 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. Note These disk space requirements mean that if you compress the Active Directory database on a single drive, you should have free space equivalent to at least 115 percent of the space that the current Active Directory database uses on that drive.

371

To perform offline defragmentation of the directory database 1. 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, before you stop AD DS, prepare a shared directory on a remote server in the domain. For example, create the share \\ServerName\NTDS. Allow access to only the Builtin Administrators group. On the domain controller, map a network drive to this shared folder. Important You should make a copy of the existing Ntds.dit file if at all possible, even if you have to store that copy on a network drive. If the compaction of the database does not work properly, you can then easily restore the database by copying back the copy of the Ntds.dit file that you made. Do not delete this copy of the Ntds.dit file until you have verified that the domain controller starts properly. 2. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 3. At the command prompt, type the following command, and then press ENTER:
net stop ntds

Type Y to agree to stop additional services, and then press ENTER. 4. At the command prompt, type ntdsutil, and then press ENTER. 5. At the ntdsutil prompt, type activate
instance ntds,

and then press ENTER.

6. At the ntdsutil prompt, type files, and then press ENTER. 7. If you are compacting the database to a local drive, 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 mapped a drive to a shared folder on a remote computer, type the drive letter only, for example, compact to K:\. Note When you compact the database 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 the directory and then creates the file named Ntds.dit in that location. 8. If defragmentation completes successfully, type quit, and then press ENTER to quit the file maintenance: prompt. Type quit again, and then press ENTER to quit Ntdsutil.exe. Go to step 9. If defragmentation completes with errors, go to step 12. Caution 372

Do not overwrite the original Ntds.dit file or delete any log files. 9. If defragmentation succeeds with no errors, follow the Ntdsutil.exe onscreen instructions to: a. To delete all the log files in the log directory, type the following command, and then press ENTER:
del <drive>:\<pathToLogFiles>\*.log

Ntdsutil provides the correct path to the log files in the onscreen instructions. Note You do not have to delete the Edb.chk file. b. You should make a copy of the existing Ntds.dit file if at all possible, even if you have to store that copy on a secured network drive. If the compaction of the database does not work properly, you can then easily restore the database by copying it back to the original location. Do not delete the copy of the Ntds.dit file until you have at least verified that the domain controller starts properly. If space allows, you can rename the original Ntds.dit file to preserve it. 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”

Ntdsutil provides the correct paths to the temporary and original locations of the Ntds.dit file. 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, the likely cause is that an error occurred during the copy operation in step 9.c. Repeat steps 9.c through step 12. If the integrity check fails again: • Or • Copy the original version of the Ntds.dit file that you preserved in step 9.b. to the original database location, and repeat the offline defragmentation procedure. 13. If the integrity check succeeds, proceed as follows: • If the initial compact through 12.
to

Contact Microsoft Customer Service and Support.

command failed, go back to step 7 and perform steps 7

• 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. 14. Restart AD DS. At the command prompt, type the following command, and then press ENTER:
net start ntds

If errors appear when you restart AD DS: 373

1. Stop AD DS. At the command prompt, type the following command, and then press ENTER:
net stop ntds

Type Y to agree to stop additional services, and then press ENTER. 2. Check the errors in Event Viewer. If the following events are logged in the Directory Service log in Event Viewer when you restart AD DS, respond to the events as follows: • Event ID 1046. “The Active Directory database engine caused an exception with the following parameters.” In this case, AD DS 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 9.c through step 12 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 9.b. to the original database location and repeat the offline defragmentation procedure. If the integrity check succeeds, follow the steps in the procedure If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup. 4. If semantic database analysis with fixup succeeds, quit Ntdsutil.exe, and then restart AD DS. At the command prompt, type the following command, and then press ENTER:
net start ntds

Contact Microsoft Customer Service and Support.

If semantic database analysis with fixup fails, contact Microsoft Customer Service and Support.

See Also
If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup

If the Database Integrity Check Fails, Perform Semantic Database Analysis with Fixup
When you move or compact the Active Directory database, if the integrity check fails, you must run a subsequent database test called semantic database analysis. 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. You can use this procedure to perform semantic database analysis with fixup.

374

Note To perform this procedure, Active Directory Domain Services (AD DS) must be offline. On domain controllers that are running Windows Server 2008, you can take AD DS offline by stopping the service. Otherwise, the domain controller must be started in Directory Services Restore Mode (DSRM). For information about stopping the AD DS service on domain controllers that are running Windows Server 2008, see the Windows Server 2008 Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=88649). For information about performing this procedure in DSRM, see If database integrity check fails, perform semantic database analysis with fixup on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=121568). Membership in Builtin Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To perform semantic database analysis with fixup 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
net stop ntds

Type Y to agree to stop additional services, and then press ENTER. 3. At the command prompt, type ntdsutil, and then press ENTER. 4. At the ntdsutil: prompt, type activate 5. At the ntdsutil: prompt, type semantic 6. At the semantic 7. At the semantic
checker: checker: instance ntds,

and then press ENTER. and then press ENTER.

database analysis, on,

prompt, type verbose prompt, type go

and then press ENTER.

fixup,

and then press ENTER.

• If errors are reported during the semantic database analysis Go Fixup phase, perform directory database recovery: Go to the file maintenance: prompt, type recover, and then press ENTER. • If semantic database analysis with fixup succeeds, at the semantic prompt, type quit, and then type quit again to close Ntdsutil.exe.
net start ntds checker

8. At the command prompt, type the following command, and then press ENTER:

Administering Domain Controllers
This guide provides information about administering Active Directory domain controllers in the Windows Server 2008 operating system. 375

In this guide • • Introduction to Administering Domain Controllers Managing Domain Controllers

Additional references
• Step-by-Step Guide for Windows Server 2008 Active Directory Domain Services Installation and Removal (http://go.microsoft.com/fwlink/?LinkId=86727)

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 tools that you can use to administer Active Directory Domain Services (AD DS) remotely • • • Install and remove AD DS to create or decommission domain controllers Rename domain controllers Add domain controllers to remote (branch) sites

Installing Remote Server Administration Tools
To manage domain controllers, you can configure a member server that is running Windows Server 2008 or a workstation that is running Windows Vista with Service Pack 1 (SP1) with the same administration tools for managing AD DS that are available on a domain controller. Administering domain controllers remotely from a member server or a workstation is more secure and more efficient than logging on to a domain controller locally. You can use Server Manager to install the Remote Server Administration Tools feature to include Active Directory Domain Services Tools.

Installing and removing AD DS
To create a new domain controller, you install AD DS on a computer that is running Windows Server 2008. 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.

376

Adding domain controllers
You might want to add a new domain controller for the following reasons: • Additional applications that use AD DS (Active Directory–integrated applications) might require increased capacity. • Additional domain controllers might be needed to provide upgrades and fault tolerance and to reduce failures. • You might add a new site where users require a domain controller for logging on to the domain. Many improvements to the installation process are available in Windows Server 2008. For information about new Windows Server 2008 features and options, see What's New in AD DS Installation and Removal (http://go.microsoft.com/fwlink/?LinkId=103330). For information about the criteria and best practices for deploying domain controllers, see Planning Domain Controller Placement (http://go.microsoft.com/fwlink/?LinkId=120383).

Removing domain controllers
When you no longer need a server to be a domain controller, you remove AD DS from the server. The process of removing AD DS is similar to the process for installing AD DS. You run many of the same tests before you remove AD DS that you run before you install AD DS. These tests ensure that the removal process occurs without any problems. If a domain controller has a hardware failure, AD DS cannot be started, and you plan to never return that domain controller to service, you must use a procedure that forces the removal of AD DS and then take additional steps to remove the server object and its metadata from the directory.

Renaming domain controllers
You often have 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 IP-to-host name mappings and that service principal names (SPNs) replicate to all domain controllers in the domain.

Adding domain controllers to branch sites
If enough directory users are employed in a branch office, especially in a site that has slow connectivity to the hub site, you might have to add a domain controller to the site to provide directory access for logons and searches. In Windows Server 2008, you have the option to deploy read-only domain controllers (RODCs). An RODC is an additional domain controller that hosts read-only directory partitions of the Active Directory database. An RODC is primarily designed to be deployed in a branch office environment. Branch offices typically have relatively few users, poor physical security, relatively poor network bandwidth to a hub site, and little local information technology (IT) expertise. RODCs receive replication updates from the hub site, but they do not accept manual updates to AD DS and they do not replicate directory updates to other domain controllers. Therefore, although security 377

precautions should be maintained, the stringent security measures that apply to protecting a writable domain controller are lessened. In addition, elevated administrative credentials are not required to install and manage the RODC. The information in this guide is specific to managing writable domain controllers. For information about managing RODCs, see Planning and Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840). When you are creating a new branch site, a local domain controller is not available to be the source for Active Directory replication. If the wide area network (WAN) connection with the closest hub site is slow or unreliable, replicating AD DS can be time consuming and might fail if the connection is lost. When you deploy the first domain controller in a branch site, if you want to avoid replicating AD DS, you have the following options: • Install the domain controller in the hub site, and then ship the installed domain controller to the site. • Ship the server computer to the branch site, and then install AD DS in the branch site. When you install the domain controller in the branch site, the server can receive AD DS in one of two ways: • • By Active Directory replication over a WAN link Directly from locally available installation media

Installing from media
Installation from media (IFM) eliminates the use of replication to create the Active Directory domain, configuration, and schema directory partition replicas on the new domain controller. Assuming that the remote site is connected to a hub site by a WAN link and that the remote site 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 contents of AD DS over the WAN link when you add the new domain controller to the remote site. In this case, you can use IFM to install AD DS. On a domain controller that is running Windows Server 2003, installation media must be created by backing up system state and restoring the backup file to a location either on the server you are installing or on removable media. The IFM process is improved in Windows Server 2008, eliminating the necessity of using the backup and restore process to create the installation media. On a domain controller that is running Windows Server 2008, you can use the Ntdsutil commandline tool to create the installation media. Then, you can use the Active Directory Domain Services Installation Wizard (Dcpromo.exe) to install AD DS from the installation media. If you want to use Ntdsutil to create the installation media to install a domain controller, both the source of the media and the target server that is to be promoted to a domain controller must be running Windows Server 2008. In addition, the operating system of the source of the backup and the target server must be the same. For example, you cannot install AD DS on a server that is running Windows Server 2003 using installation media that is created on a domain controller that is running Windows Server 2008. An improvement in the requirements for Windows Server 2008 domain controllers over the requirements for Windows Server 2003 domain controllers is that the hardware platform (32-bit or 64-bit) of the two computers does not have to match. Although information in this guide is specific to installing writable domain controllers in branch office sites, in Windows Server 2008 forests, RODCs are the recommended domain controller installation 378

for branch office sites. For information about using IFM to install RODCs, see Planning and Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).

Shipping installed domain controllers to branch sites
Shipping an existing domain controller requires removing it from the replication topology for what may be an extended period. Preparation is required to ensure a smooth transition when the domain controller restarts in the branch site. For example, you must be sure that the domain controller does not hold any operations master (also known as flexible single master operations or FSMO) roles and that replication is updated immediately before you disconnect the domain controller.

Managing Domain Controllers
The tasks that are described in this objective apply to the installation and management of Active Directory Domain Services (AD DS) on writable domain controllers. For information about installing and managing read-only domain controllers (RODCs), see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728) and Planning and Deploying Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840). The tasks that are described in this objective will help you do the following: • Install Remote Server Administration Tools (RSAT) on a member server that is running Windows Server 2008 or on a client computer that is running Windows Vista with Service Pack 1 (SP1). RSAT include a selection for Active Directory Domain Services Tools. You can install these tools on a non-domain-controller computer in the domain and then use this computer to manage domain controllers remotely. • Manage antivirus software. Antivirus software provides important safeguards. However, installation on a domain controller requires care to ensure that domain controller performance is not affected. • Prepare for Active Directory installation. Proper preparation decreases the chances of problems occurring during and after the installation. • Install 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 Domain Services (AD DS) on a server to create an additional domain controller in an existing domain: • Run the Active Directory Domain Services Installation Wizard, and use Active Directory replication to create the Active Directory replica and either the File Replication Service (FRS) or Distributed File System (DFS) Replication to create the SYSVOL replicas. • Run the Active Directory Domain Services Installation Wizard, and use installation from media (IFM) to create the Active Directory replica. Note By default, SYSVOL is created on the new domain controller by replication from a source domain controller. It does not come from the installation media. Obtaining 379

SYSVOL from installation media requires additional procedures. For information about the process for configuring the server to obtain SYSVOL from installation media, see article 311078 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=70809). • Run the Active Directory Domain Services Installation Wizard, and use an answer file to provide the information that the Active Directory Domain Services Installation Wizard requires. You can create an answer file by using the Export feature in the Active Directory Domain Services Installation Wizard during domain controller installation. • Verify installation. Perform tests to verify that AD DS 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. This process is different if you are installing an RODC. For information about installing RODCs in remote sites, see the Step-by-Step Guide for Readonly Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728). • 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 installation media that is prepared from an existing domain controller to avoid having to replicate AD DS over a wide area network (WAN) link. • Rename a domain controller. You may have to rename a domain controller for organizational or administrative reasons. • Remove AD DS from (decommission) a properly functioning domain controller. This task includes first transferring 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 Domain Services Installation Wizard cannot contact other domain controllers and DNS servers that are required for Active Directory removal. In this case, you can invoke a special version of the wizard to forcefully remove objects from AD DS that represent the server as a domain controller. This section includes the following tasks for managing domain controllers: • • • • • • • • Installing Remote Server Administration Tools for AD DS Managing Antivirus Software on Active Directory Domain Controllers Preparing for Active Directory Installation Installing a Domain Controller in an Existing Domain Verifying Active Directory Installation Adding Domain Controllers in Remote Sites Renaming a Domain Controller Decommissioning a Domain Controller 380



Forcing the Removal of a Domain Controller

Installing Remote Server Administration Tools for AD DS
When you install Active Directory Domain Services (AD DS) to create a domain controller, the administrative tools that you use to manage AD DS are installed automatically. If you want to manage domain controllers remotely from a computer that is not a domain controller, you can install the administrative tools on a member server that is running Windows Server 2008 or on a computer that is running Windows Vista with Service Pack 1 (SP1). On member servers that are running Windows Server 2008, you use the Remote Server Administration Tools (RSAT) feature in Server Manager to install Active Directory Domain Services Tools. RSAT replaces Windows Support Tools and Adminpak.msi that are used with Windows Server 2003. You can also install Active Directory Domain Services Tools on a computer that is running Windows Vista with Service Pack 1 (SP1) by downloading the tools.

Installing Active Directory Domain Services Tools on a member server that is running Windows Server 2008
You can use the following procedure to add the Active Directory Domain Services Tools component of RSAT to a member server. Membership in Builtin Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To install Active Directory Domain Services Tools on a member server 1. On the Start menu, click Server Manager. 2. Under Features Summary, click Add Features. 3. Double-click Remote Server Administration Tools, double-click Role Administration Tools, double-click Active Directory Domain Services Tools, and then click Next. 4. Click Install. 5. Click the message that indicates you must restart the server, and then click Yes to restart the server or click No to restart the server later. 6. After the server restarts, on the Installation Results page of the Resume Configuration Wizard, click Close. The Active Directory Domain Services Administration Tools are available on the Administrative Tools menu.

381

Installing Active Directory Domain Services Tools on a computer that is running Windows Vista with SP1
For information about adding the Active Directory Domain Services Tools component of RSAT to a client computer that is running Windows Vista with SP1, and to download the tools, see Microsoft Remote Server Administration Tools for Windows Vista (KB941314) (http://go.microsoft.com/fwlink/?LinkId=95703). On the download page, under Quick Details, click KB941314. Use the information and the links in the article to download the tools and select the tools that you want to install on the Windows Vista workstation.

Managing Antivirus Software on Active Directory Domain Controllers
Because domain controllers provide critical services to their clients, it is crucial to minimize the risk of any disruption of these services that may be caused by malicious code. You can generally use antivirus software to mitigate the risk of malicious code. However, installing antivirus software (from any vendor) on a domain controller and configuring it to scan everything is not a reliable or recommended solution because the antivirus software may interfere with domain controller performance. Specifically, the scanning procedures that most antivirus applications use require exclusive locks on files. In many cases, these locks can interfere with the real-time data replication that domain controllers use to stay synchronized with the rest of the network. The antivirus software that you use must be compatible with Windows operating systems in general and domain controllers in particular. Antivirus software must be installed in a manner that protects against attacks as much as possible while not interfering with domain controller performance. For example, antivirus software must be able to scan Distributed File System (DFS) files that are replicated by File Replication Service (FRS) or DFS Replication in a way that does not initiate full synchronization of files and folders in SYSVOL or of DFS roots and links. Any antivirus vendor should provide specific instructions to correctly configure their product to work with domain controllers that are running versions of Windows Server and that have Active Directory Domain Services (AD DS) installed. We cannot guarantee the interoperability of any antivirus software with DFS Replication, including any tests recommended in this guide. The need for extensive testing can be avoided completely by asking their antivirus software vendor to disclose their tested interoperability with DFS Replication. Vendors that have tested their software are happy to stand by their products. For a list of antivirus software vendors, see article 49500 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=22381).

382

Guidelines for managing antivirus software on Active Directory domain controllers
Follow the guidelines from your antivirus software vendor. Verify that the antivirus software you select is confirmed to be compatible with your domain controllers. Test your chosen antivirus software solution thoroughly in a lab environment to ensure that the software does not compromise the stability of your system. Antivirus software has been known to cause blue screens on domain controllers. Before you install antivirus software or any update to that software on domain controllers in a domain, test lab domain controllers for the following issues: • • • • Stability issues Memory leaks High CPU usage Interruptions or failure of inbound and outbound replication

The following recommendations are general and should not be construed as more important than the specific recommendations of your antivirus software vendor. These guidelines must be followed for correct Active Directory file replication operation: • 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 computers that have to interact with the domain controllers. Catching the virus at the earliest point—at the firewall or at the client computer on which the virus is first introduced—is the best way to prevent the virus from ever reaching the infrastructure systems on which all client computers depend. • Use a version of antivirus software that is confirmed to work with AD DS and that uses the correct application programming interfaces (APIs) for accessing files on the server. Some versions of antivirus software inappropriately modify file metadata as it is scanned, causing the FRS replication engine to perceive a file as having changed and to schedule it for replication. Some newer versions of antivirus software prevent this problem. For more information about antivirus software versions and FRS, see article 815263 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=120540) and see the vendor-specific sites for compliant versions. Verify antivirus compatibility with DFS Replication, as described in Testing Antivirus Application Interoperability with DFS Replication (http://go.microsoft.com/fwlink/?LinkId=122787). Note If you are using ForeFront Client Security, see article 956123 in the Microsoft Knowledge Base for a hotfix (http://go.microsoft.com/fwlink/?LinkId=131409). • Prevent the use of domain controller systems as general workstations. Users should not use a domain controller to surf the Web or to perform any other activities that can allow the introduction of malicious code. Allow browsing of known safe sites only for the purpose of supporting server operation and maintenance. • When possible, do not use a domain controller as a file sharing server. Virus scanning software must be run against all files in the shared folders, and it can place a large resource 383

load on the processor and memory resources of the server. For the same reason, the SYSVOL and Netlogon shares that are automatically created on domain controllers should not be used to distribute software or for to store data.

Files to exclude from scanning
Exclude the following files and folders from your antivirus scanning operations. These files are not at risk of infection, and including them can cause serious performance problems or loss of functionality as a result of file locking and excessive replication between domain controllers. Furthermore, scanning these files may cause AD DS, FRS, and DFS Replication to work improperly, possibly causing data loss. Where a specific set of files is identified by name, exclude only those files rather than the entire folder. In some cases, you must exclude the entire folder. Do not exclude any files that you think are not at risk based only on the file name extension. (For example, do not exclude all files with a .dit extension.) Microsoft has no control over other files that might use the same file name extension as the files shown here. Antivirus software must not modify any data files in the logs, database, or directory service working directories that are specified below. Active Directory and related files to exclude • Main NTDS database files. The location of these files is specified in: HKLM\System\Services\NTDS\Parameters\DSA Database File The default location is %systemroot%\ntds. File to exclude: • • Ntds.dit Active Directory transaction log files. The log directory on any given server is specified in:

HKLM\System\Services\NTDS\Parameters\Database Log Files Path The default location is %systemroot%\ntds. Files to exclude: • • • • EDB*.log (Notice the wildcard symbol; there can be several log files.) Edbres00001.jrs Edbres00001.jrs

The NTDS Working folder that is specified in:

HKLM\System\Services\NTDS\Parameters\DSA Working Directory Files to exclude: • • TEMP.edb EDB.chk

SYSVOL files to exclude The list in the following table shows the default locations of files and folders to be excluded or scanned for the SYSVOL directory and subdirectories when you use FRS to replicate SYSVOL.

384

Folder or File

Scan or Exclude

%systemroot%\SYSVOL %systemroot%\SYSVOL\domain %systemroot%\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory %systemroot%\SYSVOL\domain\policies %systemroot%\SYSVOL\domain\scripts %systemroot%\SYSVOL\staging %systemroot%\SYSVOL\staging areas %systemroot%\SYSVOL\sysvol FRS and related files to exclude • The FRS working directory that is specified in:

Exclude Scan Exclude Scan Scan Exclude Exclude Exclude

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Working Directory Files to exclude: • • • • <FRS working directory>\jet\sys\edb.chk <FRS working directory>\jet\ntfrs.jdb <FRS Working Directory>\jet\log\*.log

The FRS database log files that are specified in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\DB Log File Directory The default location is %systemroot%\ntds. Files to exclude: • • • <FRS working directory>\jet\log\*.log (if the registry entry is not set) <Database log file directory>\log\*.log (if the registry entry is set)

FRS Replica_root files that are specified in:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\Replica Sets\GUID\Replica Set Root • The staging directory in: HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\Replica Sets\GUID\Replica Set Stage • The FRS Preinstall directory at: <Replica_root>\DO_NOT_REMOVE_NtFrs_PreInstall_Directory. The Preinstall directory is always open when FRS is running. DFS Replication and related files to exclude 385

• System Volume Information\DFSR folders and their contents (includes DFSR.DB). This system-protected directory contains working files for the DFS Replication service. It should not be scanned because these files are always in use by the service. • <Replicated folder path>\dfsrprivate folders and their contents

Preparing for Active Directory Installation
Properly preparing for the installation of Active Directory Domain Services (AD DS) decreases the chances of problems occurring during the installation process and helps you complete the installation quickly. There are a number of requirements for installing AD DS on a new domain controller in an existing domain. Preparation includes configuring DNS and gathering information that you need for the installation. This section describes general requirements with respect to Domain Name System (DNS) configuration, placement of the domain controller in a site, and connectivity for the Active Directory Domain Services Installation Wizard. After you have gathered all the information that you need to run the Active Directory Domain Services Installation Wizard and you have performed the tests to verify that all the necessary domain controllers are available, you are ready to install AD DS on your server and create an additional domain controller in your domain.

DNS configuration
The DNS Client service is always present on a server running Windows Server 2008. A DNS server must be present in an Active Directory forest, and the DNS server must store DNS data for the server computer that you are installing. You should 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 AD DS. For ease of administration, install the DNS Server service when you install AD DS. When you use the Active Directory Domain Services Installation Wizard to install the DNS Server service, DNS zones, zone delegations, root hints or forwarders, and DNS client settings are configured automatically. Ensure that any required configuration, forwarders, or zones are present and accessible before installation. For more information about DNS configuration in preparation for domain controller installation, see Integrating AD DS into an Existing DNS Infrastructure (http://go.microsoft.com/fwlink/?LinkId=120585).

Site placement
During Active Directory installation, the Active Directory Domain Services Installation Wizard attempts to place the new domain controller in the appropriate site. You can select a source replication partner, the site for the new domain controller, or both when you use the wizard to install AD DS. The appropriate site is determined by the domain controller’s IP address and subnet mask. 386

The wizard uses the IP information to calculate the subnet address of the domain controller. The wizard then 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 the subnet object does not exist, if you do not specify a site, 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 that the subnet object has been created and that it is associated with the target site before you run the wizard. For information about creating a subnet and associating it with a site, see Create a Subnet Object or Objects and Associate them with a Site.

Domain connectivity
During the installation process, the Active Directory Domain Services Installation Wizard must communicate with other domain controllers to join the new domain controller to the domain. The wizard must communicate with a member of the domain to receive the initial copy of the directory database for the new domain controller. The wizard communicates with the domain controller that holds the domain naming operations master (also known as flexible single master operations or FSMO) role for domain installations only, so that the new domain controller can be added to the domain. The wizard must also contact the relative ID (RID) operations master so that the new domain controller can receive its RID pool, and the wizard must communicate with another domain controller in the domain to populate the SYSVOL shared folder on the new domain controller. All of this communication depends on proper DNS installation and configuration. By using Dcdiag.exe, you can test all of these connections before you start the Active Directory Domain Services Installation Wizard. Task requirements During the installation process, the wizard must 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 Directory–integrated 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 Domain Services Installation Wizard asks for the following specific configuration information before it begins installing AD DS: • • A domain administrator’s user name and password A location to store the directory database and log files 387

• •

A location to store SYSVOL The password to use for Directory Services Restore Mode (DSRM)

• The fully qualified DNS name of the domain to which the new domain controller will be added • • • Dcdiag.exe Network Connections Active Directory Sites and Services

To complete this task, perform the following procedures: 1. Verify DNS Infrastructure and Registrations 2. Verify That an IP Address Maps to a Subnet and Determine the Site Association 3. Verify the Availability of the Operations Masters Caution If any verification test fails, do not continue until you determine what went wrong and you fix the problems. If one or more of these tests fail, the installation of AD DS is also likely to fail.

Verify DNS Infrastructure and Registrations
You can use this procedure to verify that the existing Domain Name System (DNS) infrastructure is sufficient for installing Active Directory Domain Services (AD DS) on the installation computer in the specified domain. This test reports whether any modifications to the existing DNS infrastructure are required so that the server can dynamically register DNS records that are required for the location of the domain controller by other devices on the network. Although the Active Directory Domain Services Installation Wizard presents a warning message during Active Directory installation if it encounters DNS registration errors, failure of this test does not prevent you from running the wizard. However, failed DNS registrations will prevent the domain controller from functioning properly on the network. Therefore, resolve any problems that this test reports before you install AD DS. Because all Dcdiag tests include a connectivity test, this procedure also tests TCP/IP connectivity. To complete this procedure, you must have Dcdiag.exe installed on the server. During the initial part of the installation of AD DS, you use Server Manager to add the Active Directory Domain Services server role. This part of the installation procedure installs the Dcdiag.exe command line tool. The second part of the installation process, running Dcpromo.exe, actually installs AD DS. Perform the Dcdiag test procedure after you add the Active Directory Domain Services server role but before you run Dcpromo.exe. Note If you do not want to install the Active Directory Domain Services server role at this time, you can install the Active Directory Domain Services Administration Tools, which include Dcdiag.exe, by using Add Features in Server Manager. For information about using Add 388

Features to install the Active Directory Domain Services Administration Tools, see Installing Remote Server Administration Tools for AD DS. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify the DNS infrastructure and registrations 1. If you do not want to install AD DS at this time but you want to perform DNS verification tests, install the Active Directory Domain Services Administrative Tools, as described in Installing Remote Server Administration Tools for AD DS, and then go to step 9. 2. If you want to install Dcdiag.exe during the installation of AD DS and run the DNS test before you run Dcpromo.exe, click Start, and then click Server Manager. 3. In Roles Summary, click Add Roles. 4. Review the information on the Before You Begin page, and then click Next. 5. On the Select Server Roles page, click Active Directory Domain Services, and then click Next. 6. Review the information on the Active Directory Domain Services page, and then click Next. 7. On the Confirm Installation Selections page, click Install. 8. On the Installation Results page, do not click Close this wizard and launch the Active Directory Domain Services Installation Wizard (dcpromo.exe). First, perform steps 9 and 10. When you have completed the Dcpromo test successfully, return to the Installation Results page and continue with the installation of the Active Directory Domain Services server role. 9. Open a Command Prompt window as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 10. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:dcpromo /DnsDomain:<DNSDomainName> /ReplicaDC

where <DNSDomainName> is the DNS name of the domain, in the form <DomainName.ForestName>, in which you want to add a domain controller. 11. If the server does not pass the Dcpromo test, fix the reported problems before you continue with the installation of AD DS.

389

Verify That an IP Address Maps to a Subnet and Determine the Site Association
You can use this procedure to determine the site to which you want to add a server object before you install Active Directory Domain Services (AD DS). You can also use this procedure to verify the site after you install AD DS or before you move a server object. To be associated with a site, the IP address of a domain controller must map to a subnet object that is defined in AD DS. 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 AD DS. When you know the subnet address, you can locate the subnet object and determine the site to which the subnet is associated. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify that an IP address maps to a subnet and to determine the site association 1. Log on locally or open a Remote Desktop connection to the server for which you want to check the IP address. 2. In Server Manager, click View Network Connections. 3. Right-click the connection that represents the connection the server or domain controller uses to attach to the network, and then click Properties. 4. In the Connection Properties dialog box, double-click Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol Version 6 (TCP/IPv6). 5. Use an IP subnet calculator and the values in IP address and Subnet mask to calculate the subnet address, and then click OK twice. 6. Open the Active Directory Sites and Services snap-in: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 7. Expand the Sites container, and then click the Subnets container. 8. In the Name column in the details pane, find the subnet object that matches the subnet address for the server or domain controller. 9. In the Site column, note the site to which the IP subnet address is associated. If the site that appears in the Site column is not the appropriate site, contact a site administrator and find out whether the IP address is incorrect or whether you should move the server object to the site that is indicated by the subnet-to-site association.

See Also
Move a Server Object to a New Site 390

Verify the Availability of the Operations Masters
You can use this procedure to verify that the domain controllers that hold the operations master (also known as flexible single master operations or FSMO) roles can be located and that they are online and responding. You can use the tests in this procedure before you install Active Directory Domain Services (AD DS) as well as afterward. However, if you perform this procedure before you install AD DS, you must do the following: • First, use Server Manager to add the Active Directory Domain Services server role. This part of the installation procedure installs the Dcdiag.exe command line tool. Perform this procedure after you add the server role but before you run Dcpromo.exe. • Use the /s command option to indicate the name of an existing domain controller in the domain of the new domain controller. This domain controller is required to verify the ability of the server to connect to operations master role holders in the domain and forest. You do not have to use the /s option if you perform the test in this procedure after you install AD DS. The test automatically runs on the local domain controller where you are performing the test. The commands in this procedure show the /s option. If you are performing this test after you install AD DS, 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. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify the availability of the operations masters 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command to ensure that the operations masters can be located, and then press ENTER:
dcdiag /s:<DomainControllerName> /test:knowsofroleholders /v

where <DomainControllerName> is the name of an existing 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. 3. Type the following command to ensure that the operations masters are functioning properly and available on the network, and then press ENTER: 391

dcdiag /s:<DomainControllerName> /test:fsmocheck

where <DomainControllerName> 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 as well as other important servers, such as global catalog servers and time servers. Near the bottom of your screen, a message confirms that the test succeeded. If these tests fail, do not attempt any additional steps until you fix the problem that prevents the location of operations masters and you can verify that they are functioning properly.

Installing a Domain Controller in an Existing Domain
This section describes methods for installing Active Directory Domain Services (AD DS) onto a Windows Server 2008 server that will become a domain controller in an existing Active Directory domain. The procedures in this section provide instructions for installing AD DS by using replication to create the new domain controller or by using installation media. By using the installation from media (IFM) method, you can avoid replicating AD DS over the network. Note This section describes methods for installing writable domain controllers. For information about installing read-only domain controllers (RODCs), see the Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728) and Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/? LinkId=120840). The following methods use replication to create the new domain controller: • Active Directory Domain Services Installation Wizard (Dcpromo.exe), by specifying a source domain controller or allowing the replication system to select a replication partner. • Unattended installation, by instructing Dcpromo to use parameters in an answer file to install AD DS. The answer file either specifies a source domain controller or allows the replication system to select a replication partner. • Command-line installation, by using unattend parameters that either specify a source domain controller or allow the replication system to select a replication partner. The following methods use installation media as the source for Active Directory installation, which avoids replication of AD DS: • Active Directory Domain Services Installation Wizard (Dcpromo.exe), by using advanced options and specifying the location of installation media (the IFM method). • Unattended installation, by instructing Dcpromo to use parameters in an answer file to install AD DS. The answer file specifies the location of installation media.

392

• Command-line installation, by using unattend parameters to specify the location of installation media. Before you perform the installation procedures, prepare the server for installation according to the instructions in Preparing for Active Directory Installation. To ensure successful installation of a new domain controller, verify that all critical services that AD DS depends on are configured according to Requirements for Installing AD DS (http://go.microsoft.com/fwlink/?LinkId=120603). If you are installing the first Windows Server 2008 domain controller in an existing Windows Server 2000 or Windows Server 2003 domain, see the domain and forest preparation information in Installing an Additional Windows Server 2008 Domain Controller (http://go.microsoft.com/fwlink/?LinkID=93254). For information about best practices for planning, testing, and deploying AD DS, see the AD DS Design Guide (http://go.microsoft.com/fwlink/?LinkID=116282) and see the AD DS Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=116283). This section includes the following tasks for installing a domain controller in an existing domain: • • • Installing an Additional Domain Controller by Using the Windows Interface Installing an Additional Domain Controller by Using IFM Installing an Additional Domain Controller by Using Unattend Parameters

See Also
Preparing for Active Directory Installation

Installing an Additional Domain Controller by Using the Windows Interface
The Windows interface provides two wizards that guide you through the process of installing Active Directory Domain Services (AD DS). The first wizard is the Add Roles Wizard, which you can access in Server Manager. The second wizard is the Active Directory Domain Services Installation Wizard, which you can access in the following ways: • When you complete the Add Roles Wizard in Server Manager, click the link to start the Active Directory Domain Services Installation Wizard. • Click Start, click Run, type dcpromo.exe, and then click OK. If you use the advanced options in the Active Directory Domain Services Installation Wizard, you can control how AD DS is installed on the server, either by installation from media (IFM) or by replication: • IFM: You can provide a location for installation media that you have created by using Ntdsutil.exe or that you have created by restoring a critical-volume backup of a similar domain controller in the same domain to an alternate location. If you create the installation media by using Ntdsutil, you have the option to create secure installation media for a read-only domain controller (RODC). In this case, the Ntdsutil process removes cached secrets (such as 393

passwords) from the installation media. For information about using IFM to install an RODC, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/? LinkId=120840). You can also create installation media by restoring an Active Directory backup to an alternate location. For information about creating installation media by restoring a criticalvolume backup to an alternate location, see Restoring a Critical-Volume Backup to an Alternate Location (http://go.microsoft.com/fwlink/?LinkId=120612). • Replication: You can specify a domain controller in the domain from which to replicate AD DS. To complete this task, perform one of the following procedures: • Install an Additional Domain Controller by Using the Windows Interface

See Also
Installing an Additional Domain Controller by Using Unattend Parameters Installing an Additional Domain Controller by Using Unattend Parameters

Install an Additional Domain Controller by Using the Windows Interface
You can use this procedure to add the Active Directory Domain Services (AD DS) server role to a server to create a domain controller in an existing domain. You can complete this procedure by using the Windows graphical user interface (GUI). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To install an additional domain controller by using the Windows interface 1. Click Start, and then click Server Manager. 2. In Roles Summary, click Add Roles. 3. Review the information on the Before You Begin page, and then click Next. 4. On the Select Server Roles page, click Active Directory Domain Services, and then click Next. 5. Review the information on the Active Directory Domain Services page, and then click Next. 6. On the Confirm Installation Selections page, click Install. 7. On the Installation Results page, click Close this wizard and launch the Active Directory Domain Services Installation Wizard (dcpromo.exe). 8. On the Welcome to the Active Directory Domain Services Installation Wizard page, click Next. 394

You can click Use advanced mode installation to see additional installation options. Specifically, click Use advanced mode installation if you want to install from media or identify the source domain controller for Active Directory replication. 9. On the Operating System Compatibility page, review the warning about the default security settings for Windows Server 2008 domain controllers, and then click Next. 10. On the Choose a Deployment Configuration page, click Existing forest, click Add a domain controller to an existing domain, and then click Next. 11. On the Network Credentials page, type the name of any existing domain in the forest where you plan to install the additional domain controller. Under Specify the account credentials to use to perform the installation, click My current logged on credentials or click Alternate credentials, and then click Set. In the Windows Security dialog box, provide the user name and password for an account that can install the additional domain controller. To install an additional domain controller, you must be a member of the Enterprise Admins group or the Domain Admins group. When you are finished providing credentials, click Next. 12. On the Select a Domain page, select the domain of the new domain controller, and then click Next. 13. On the Select a Site page, select a site from the list or select the option to install the domain controller in the site that corresponds to its IP address, and then click Next. 14. On the Additional Domain Controller Options page, make the following selections, and then click Next: • DNS server: This option is selected by default so that your domain controller can function as a DNS server. If you do not want the domain controller to be a DNS server, clear this option. Note If you select the option to make this domain controller a DNS server, you might receive a message that indicates that a DNS delegation for the DNS server could not be created and that you should manually create a DNS delegation to the DNS server to ensure reliable name resolution. If you are installing an additional domain controller in either the forest root domain or a tree root domain, you do not have to create the DNS delegation. In this case, click Yes, and disregard the message. • Global Catalog: This option is selected by default. It adds the global catalog, readonly directory partitions to the domain controller, and it enables global catalog search functionality. • Read-only domain controller. This option is not selected by default. It makes the additional domain controller a read-only domain controller (RODC). 15. If you selected Use advanced mode installation on the Welcome page, the Install from Media page appears. You can provide the location of installation media to be used to create the domain controller and configure AD DS, or you can have all source replication occur over the network. Note that some data will be replicated over the network even if you 395

install from media. For information about using this method to install the domain controller, see Installing an Additional Domain Controller by Using IFM. 16. If you selected Use advanced mode installation on the Welcome page, the Source Domain Controller page appears. Click Let the wizard choose an appropriate domain controller or click Use this specific domain controller to specify a domain controller that you want to provide as a source for replication to create the new domain controller, and then click Next. If you do not choose to install from media, all data will be replicated from this source domain controller. 17. On the Location for Database, Log Files, and SYSVOL page, type or browse to the volume and folder locations for the database file, the directory service log files, and the SYSVOL files, and then click Next. Windows Server Backup backs up the directory service by volume. For backup and recovery efficiency, store these files on separate volumes that do not contain applications or other nondirectory files. 18. On the Directory Services Restore Mode Administrator Password page, type and confirm the restore mode password, and then click Next. This password must be used to start AD DS in Directory Services Restore Mode (DSRM) for tasks that must be performed offline. 19. On the Summary page, review your selections. Click Back to change any selections, if necessary. To save the settings that you have selected to an answer file that you can use to automate subsequent Active Directory operations, click Export settings. Type the name for your answer file, and then click Save. When you are sure that your selections are accurate, click Next to install AD DS. Note If you are installing an additional domain controller in a child domain and you are using child domain credentials, the Windows Security dialog box appears because access is denied in the parent domain to update the DNS delegation in the parent zone. In this case, click the other user icon and provide administrator credentials for the parent domain, and then click OK. 20. On the Completing the Active Directory Domain Services Installation Wizard page, click Finish. 21. You can select Reboot on completion to have the server restart automatically, or you can restart the server to complete the installation of AD DS when you are prompted to do so.

See Also
Preparing for Active Directory Installation Verifying Active Directory Installation

396

Installing an Additional Domain Controller by Using IFM
When you install Active Directory Domain Services (AD DS) by using the install from media (IFM) method, 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 that is necessary to install the additional domain controller. Windows Server 2008 includes an improved version of the Ntdsutil tool that you can use to create installation media for an additional domain controller. You can use Ntdsutil.exe to create installation media for additional domain controllers that you are creating in a domain. The IFM method uses the data in the installation media to install AD DS, which eliminates the need to replicate every object from a partner domain controller. However, objects that were modified, added, or deleted since the installation media was created must be replicated. If the installation media was created recently, the amount of replication that is required is considerably less than the amount of replication that is required for a regular AD DS installation. You can also create installation media by restoring a critical-volume backup of a similar domain controller in the same domain to an alternate location. For information about creating installation media by restoring a critical-volume backup to an alternate location, see Restoring a CriticalVolume Backup to an Alternate Location (http://go.microsoft.com/fwlink/?LinkID=120612). Note You cannot restore a system state backup to an alternate location. A system state backup can only be restored on the local domain controller, and therefore this type of backup is not appropriate for creating installation media. To use this method of creating installation media, you must restore a critical-volume backup. 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. For more information about installing additional domain controllers in remote sites, see Adding Domain Controllers in Remote Sites. IFM has the following requirements: • You cannot use IFM to create the first domain controller in a domain. A Windows Server 2008–based domain controller must be running in the domain before you can perform IFM installations. • The media that you use to create additional domain controllers must be taken from a domain controller in the same domain as the domain of the new domain controller. • If the domain controller that you are creating is to be a global catalog server, the media for the installation must be created on an existing global catalog server in the domain. • To install a domain controller that is a Domain Name System (DNS) server, you must create the installation media on a domain controller that is a DNS server in the domain.

397

• To create installation media for a full (writable) domain controller, you must run the ntdsutil ifm command on a writable domain controller that is running Windows Server 2008. Note You cannot run the ntdsutil ifm command on a domain controller that runs Windows Server 2003. However, you can create a system state backup of a Windows Server 2003 domain controller, restore the backup to an alternate location, and then use the dcpromo /adv command to create a Windows Server 2003 domain controller. For information about performing IFM installations on domain controllers that are running Windows Server 2003, see Installing a Domain Controller in an Existing Domain Using Restored Backup Media (http://go.microsoft.com/fwlink/? LinkId=120623). • To create installation media for a read-only domain controller (RODC), you can run the ntdsutil ifm command on either a writable domain controller or an RODC that runs Windows Server 2008. For RODC installation media, Ntdsutil removes any cached secrets, such as passwords. For more information about installing and managing RODCs, see the Stepby-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/? LinkId=92728). • You can use a 32-bit domain controller to generate installation media for a 64-bit domain controller, and the reverse is also true. The ability to mix processor types for IFM installations is new in Windows Server 2008. Ntdsutil.exe can create the two types of installation media, as described in the following table.
Type of installation media Parameter Description

Full (writable) domain controller

Create Full PathToMediaFolder

Creates installation media for a writable domain controller or an Active Directory Lightweight Directory Services (AD LDS) instance in the folder that is identified in the path. If you are creating media in a shared folder on another computer, map a network drive to the folder before you perform the procedure. Creates installation media for an RODC in the folder that is identified in the path

Read-only domain controller

Create RODC PathToMediaFolder

Task requirements The following tools are required to perform the procedures for this task: • Ntdsutil.exe 398



Dcpromo.exe

To complete this task, perform the following procedures: 1. Create Installation Media by Using Ntdsutil 2. Install an Additional Domain Controller by Using Installation Media

See Also
Verifying Active Directory Installation Adding Domain Controllers in Remote Sites

Create Installation Media by Using Ntdsutil
You can use the following procedure to create installation media for installing Active Directory Domain Services (AD DS) to create a new domain controller in an existing domain. Create the media on a domain controller in the domain where you are installing one or more new domain controllers. This procedure uses Ntdsutil to create installation media. You can also create installation media by restoring a critical-volume backup to an alternate location. This method is not recommended because it takes significantly longer than the Ntdsutil method and it requires more space for the installation media, which contains more data than is required for installing AD DS. For more information, see Restoring a Critical-Volume Backup to an Alternate Location (http://go.microsoft.com/fwlink/?LinkID=120612). The ability to log on to a domain controller locally and to back up a domain controller is the minimum required to complete this procedure. Members of Builtin Administrators, Enterprise Admins, Domain Admins, Backup Operators, and Server Operators have these rights by default. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. On a read-only domain controller (RODC), a delegated user can create the installation media. However, that user can create only RODC installation media (not installation media for a writable domain controller) on an RODC. To create installation media for IFM 1. Open a command prompt as an administrator: Click Start, right-click Command Prompt, and then click Run as administrator. 2. Type the following command, and then press ENTER:
ntdsutil

3. At the ntdsutil prompt, type the following command, and then press ENTER:
activate instance ntds

4. At the ntdsutil prompt, type the following command, and then press ENTER:
ifm

399

5. At the ifm prompt, type the command for the type of installation media that you want to create, and then press ENTER. For example, to create installation media for a read-write domain controller, type the following command:
Create full <Drive>:\<InstallationMediaFolder>

Where <Drive>:\<InstallationMediaFolder> is the path to the folder where you want the installation media to be created. You can save the installation media to a network shared folder or to removable media. When you create additional domain controllers in the domain, you can refer to the shared folder or removable media where you store the installation media as follows: • In the Active Directory Domain Services Installation Wizard: on the Install from Media page • In an unattended installation answer file: in the /ReplicationSourcePath parameter

See Also
Create an Answer File for Unattended Domain Controller Installation Installing an Additional Domain Controller by Using IFM

Install an Additional Domain Controller by Using Installation Media
You can use this procedure to install Active Directory Domain Services (AD DS) from media. You can use the install from media (IFM) method to create an additional domain controller in an existing domain. When you create an additional domain controller in the domain, you can specify sourcing the installation from the shared folder or removable media where you created the installation media by using one of the following methods: • Windows interface: Provide the location on the Install from Media page in the Active Directory Domain Services Installation Wizard. • Unattended installation: Use the /ReplicationSourcePath parameter in the answer file for an unattended installation. • Command line: Use the /ReplicationSourcePath unattend parameter at the command line. Membership in the Domain Admins group in the domain into which you are installing the additional domain controller, or the equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

400

To install AD DS from IFM media by using the Windows interface 1. Use the procedure Install an Additional Domain Controller by Using the Windows Interface. In step 8, select Use advanced mode installation. 2. In step 15, select the install from media option and provide the location of the installation media. 3. Complete the remaining pages of the Active Directory Domain Services Installation Wizard. 4. After the installation operation completes successfully and the computer is restarted, remove the folder that contains the IFM media from the local disk. To install AD DS from IFM media by using an answer file 1. Create an answer file by using one of the following methods: • During the procedure Install an Additional Domain Controller by Using the Windows Interface, select the Export settings option to save the installation settings to a file. This file is an answer file that you can use to install an additional domain controller in the same domain. • Use the procedure Create an Answer File for Unattended Domain Controller Installation to create an answer file. Include the /ReplicationSourcePath parameter to specify the location of the IFM media. 2. Use the procedure Install an Additional Domain Controller by Using an Answer File to install AD DS. To install AD DS from IFM media by using unattend parameters from the command line 1. Use the procedure Install an Additional Domain Controller by Using Unattend Parameters from the Command Line to install AD DS. 2. During the procedure, use the /ReplicationSourcePath parameter to specify the location of the IFM media.

See Also
Preparing for Active Directory Installation Verifying Active Directory Installation

Installing an Additional Domain Controller by Using Unattend Parameters
You can use unattend parameters to specify configuration settings for installing Active Directory Domain Services (AD DS) to create an additional domain controller in an existing domain. Specifically, you can use the dcpromo /unattend command to install AD DS. 401

You can use unattend parameters in the following ways: • In an answer file: You can manually create an answer file that contains unattend parameters to specify the settings for a domain controller, including such values as its name, domain, site, and whether it is a writable domain controller or read-only domain controller (RODC). You can also create an answer file automatically by exporting installation settings to a file during an Active Directory Domain Services Installation Wizard installation. Note For information about installing RODCs, see Step-by-Step Guide for Read-only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=92728) and Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/? LinkId=120840). • From the command line: You can type the parameters and values manually at the command line. Running an unattended installation simplifies the process of installing and configuring Active Directory Domain Services (AD DS) on multiple computers. When you use Dcpromo to reference the answer file, the installation proceeds from start to completion without user intervention. This method is most useful when you want to install AD DS with identical options on many computers. Task requirements The following tools are required to complete this task: • • Text editor application Dcpromo.exe

To complete this task, perform the following procedures: 1. Create an Answer File for Unattended Domain Controller Installation 2. Install an Additional Domain Controller by Using an Answer File 3. Install an Additional Domain Controller by Using Unattend Parameters from the Command Line

See Also
Installing an Additional Domain Controller by Using IFM Installing an Additional Domain Controller by Using the Windows Interface

Create an Answer File for Unattended Domain Controller Installation
You can use this procedure to create a text file that you can use as the answer file for an unattended installation of an additional domain controller. Use the answer file to install Active Directory Domain Services (AD DS) on either a full installation of Windows Server 2008 or a 402

Server Core installation of Windows Server 2008. The answer file contains sensitive information, and it should be kept in a secure location. Notes • The answer file that you use to install an additional domain controller in an existing domain must have the /ReplicaOrNewDomain and /ReplicaDomainDNSName parameters specified. • The answer file that you use to install a domain controller from media must have the /ReplicationSourcePath parameter specified. Any account that has Read and Write privileges for the text editor application is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To create an answer file for installing a new domain controller 1. Open Notepad or any text editor. 2. On the first line, type [DCINSTALL], and then press ENTER. 3. Create the following entries, one entry on each line. These options are the minimum options that are required for an additional domain controller installation with Domain Name System (DNS) and the global catalog installed and configured automatically. For a complete list of unattended installation options, including default values, allowed values, and descriptions, see Promotion Operation (http://go.microsoft.com/fwlink/? LinkID=120626). 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. UserDomain=Domain name for the user account in UserName Password=Password for the account in UserName. If you leave this blank, Dcpromo prompts the installer for a password during installation. Dcpromo deletes this value after installation. ReplicaDomainDNSName=The fully qualified domain name (FQDN) of the domain of the new domain controller. ReplicaOrNewDomain=Replica for an additional domain controller in an existing domain or NewDomain for the first domain controller in a new domain. DatabasePath=Location of the Ntds.dit file—a folder on a local volume, surrounded by double quotation marks. (The default is “%systemroot%\ntds”.) If you omit this entry, Dcpromo uses the default location. LogPath=Location of the database log files—a folder on a local volume, surrounded by double quotation marks. (The default is “%systemroot%\ntds”.) If you omit this entry, Dcpromo uses the default location. SYSVOLPath=Location of the SYSVOL tree—a folder on a local volume, surrounded by double quotation marks. (The default is “%systemroot%\SYSVOL”.) If you omit this entry, Dcpromo uses the default location. 403

InstallDNS=Yes to make the domain controller a DNS server or no to create a domain controller without DNS installed. ConfirmGC=Yes to make the domain controller a global catalog server or No to create a domain controller without the global catalog read-only directory partitions. SafeModeAdminPassword=Password for the administrator account that must be used to start the domain controller in Directory Services Restore Mode (DSRM). If you leave this blank, Dcpromo prompts the installer for the password during installation. Dcpromo deletes this value after installation. Passwords are removed from the answer file when you run Dcpromo. RebootOnCompletion=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. 4. If you want to include application directory partitions in the answer file, add the following parameter: ApplicationPartitionsToReplicate= 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" 5. 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 shared folder or removable media for distribution.

See Also
Install an Additional Domain Controller by Using an Answer File Install an Additional Domain Controller by Using Unattend Parameters from the Command Line

Install an Additional Domain Controller by Using an Answer File
You can use this procedure to install an additional domain controller in an existing domain. To perform this procedure, you must have created an answer file. You can create an answer file automatically when you install a domain controller using the Active Directory Domain Services 404

Installation Wizard by selecting the option to export the installation information to a file. For information about creating an answer file manually, see Create an Answer File for Unattended Domain Controller Installation. Note You can also use an answer file to create a new domain. After you create the answer file, use the following procedure to perform the unattended installation. You can use this procedure to install Active Directory Domain Services (AD DS) on either a full installation of Windows Server 2008 or a Server Core installation of Windows Server 2008. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To install a new domain controller by using an answer file • Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. • At the command prompt, type the following command, and then press ENTER:

dcpromo /unattend:"<path to the answer file>"

See Also
Preparing for Active Directory Installation Create an Answer File for Unattended Domain Controller Installation Verifying Active Directory Installation

Install an Additional Domain Controller by Using Unattend Parameters from the Command Line
You can use the following procedure to install a new domain controller from the command line. In this method of installation, you type unattended installation parameters at the command line rather than creating an answer file. For a complete list of unattended installation options, including default values, allowed values, and descriptions, type dcpromo /?:Promotion at a command prompt, or see Promotion Operation (http://go.microsoft.com/fwlink/?LinkID=120626). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

405

To install an additional domain controller by entering unattended installation parameters at the command line • At a command prompt, type the following command. When you have typed all the options that are required to create the additional domain controller, press ENTER.
dcpromo /unattend /<unattendOption>:<value> /<unattendOption>:<value> ...

Where: • • is an option in the Promotion Operation table. Separate each <option:value> pair with a space.
<unattendOption> <value>

is the configuration instruction for the option.

The following example creates an additional domain controller with the global catalog, and it installs and configures the DNS Server service:
dcpromo /unattend /InstallDns:yes /confirmGC:yes /replicaOrNewDomain:replica /databasePath:"e:\ntds" /logPath:"e:\ntdslogs" /sysvolpath:"g:\sysvol" /safeModeAdminPassword:FH#3573.cK /rebootOnCompletion:yes

Verifying Active Directory Installation
There are several verification tasks that you can perform on a computer on which Active Directory Domain Services (AD DS) has been newly installed. Successfully completing the requirements of each verification task will provide a strong indication of a healthy, operational domain controller. The individual procedures in this task are provided so that you can test specific criteria to determine the health of an Active Directory installation. To thoroughly test the domain controller for all directory service issues, you can run the dcdiag /v command. The output of this command provides detailed information about the conditions on the domain controller. For information about using the Dcdiag.exe command-line tool, see Dcdiag (http://go.microsoft.com/fwlink/?LinkId=104689). Task requirements The following tools are recommended to perform the procedures for this task: • • • • • Active Directory Sites and Services DNS Manager Event Viewer 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 Check that the new domain controller is located in the correct site so that the new domain controller can locate replication partners and become part of the replication topology. 406

3. Move a Server Object to a New Site If you have performed an unattended installation and the domain controller was not placed in the site that you expected, you can move the server object to the correct site. 4. Configure DNS Server Forwarders 5. Complete all procedures for the Verifying DNS Configuration task. 6. Check the Status of the SYSVOL and Netlogon Shares 7. Verify DNS Registration and TCP/IP Connectivity 8. Verify a Domain Computer Account for a New Domain Controller 9. Verify Active Directory Replication 10. Verify the Availability of the Operations Masters

Verify That an IP Address Maps to a Subnet and Determine the Site Association
You can use this procedure to determine the site to which you want to add a server object before you install Active Directory Domain Services (AD DS). You can also use this procedure to verify the site after you install AD DS or before you move a server object. To be associated with a site, the IP address of a domain controller must map to a subnet object that is defined in AD DS. 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 AD DS. When you know the subnet address, you can locate the subnet object and determine the site to which the subnet is associated. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify that an IP address maps to a subnet and to determine the site association 1. Log on locally or open a Remote Desktop connection to the server for which you want to check the IP address. 2. In Server Manager, click View Network Connections. 3. Right-click the connection that represents the connection the server or domain controller uses to attach to the network, and then click Properties. 4. In the Connection Properties dialog box, double-click Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol Version 6 (TCP/IPv6). 5. Use an IP subnet calculator and the values in IP address and Subnet mask to calculate the subnet address, and then click OK twice. 6. Open the Active Directory Sites and Services snap-in: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and 407

then click Continue. 7. Expand the Sites container, and then click the Subnets container. 8. In the Name column in the details pane, find the subnet object that matches the subnet address for the server or domain controller. 9. In the Site column, note the site to which the IP subnet address is associated. If the site that appears in the Site column is not the appropriate site, contact a site administrator and find out whether the IP address is incorrect or whether you should move the server object to the site that is indicated by the subnet-to-site association.

See Also
Move a Server Object to a New Site

Configure DNS Server Forwarders
You can use this procedure to configure Domain Name System (DNS) server forwarders. When you add a new domain controller that is a DNS server, if your network uses forwarding for recursive name resolution, configure DNS server forwarders based on the forwarding method that is established on your network. When forwarders are configured, a DNS server that receives a DNS query for a name for which it is not authoritative forwards the request to the DNS forwarder instead of using root hints. If your network uses forwarding, use the DNS snap-in to add the appropriate forwarders on the new domain controller. If you want the DNS Server service on the new domain controller to forward queries to different servers depending on the DNS suffix that is specified in the query, configure conditional forwarding appropriately. For information about using forwarding and conditional forwarding for DNS name resolution, see Using Forwarding (http://go.microsoft.com/fwlink/?LinkId=26353). Note Root hints is the recommended method of recursive name resolution for Active Directory– integrated DNS in Windows Server 2008 forests. For more information about configuring DNS for Windows Server 2008 forests, see the AD DS Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=116283). Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure DNS server forwarders 1. If your network uses root hints as the DNS forwarding method, you do not have to perform any additional options. Root hints are configured automatically during installation. Do not continue to step 2. 2. If you have to configure forwarders, open the DNS snap-in, and continue to step 3. 408

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, click Edit. 5. Click the text entry area where indicated, type an IP address or DNS name for a DNS server that will receive forwarded DNS queries, and then click OK. 6. When the IP address resolves to the server’s fully qualified domain name (FQDN) on the Forwarders tab, click OK.

Verifying DNS Configuration
Part of verifying Active Directory installation is verifying that Domain Name System (DNS) is installed and configured appropriately. Regarding DNS configuration for Active Directory forests, we recommend that you install the DNS Server service on all domain controllers. When you use the Active Directory Domain Services Installation Wizard to install DNS during installation of Active Directory Domain Services (AD DS), the wizard creates the DNS zone delegation automatically. The Net Logon service registers the required host and service resource records for the new domain controller when it restarts after installation. The DNS Client service on a domain controller determines the DNS servers that the domain controller uses to locate other domain controllers. Verify that the primary and alternate DNS server settings are appropriate for the network segment. Task requirements The following tools are required to perform the procedures for this task: • • DNS snap-in Network Connections

To complete this task, perform the following procedures: 1. Verify DNS Server Configuration for a Domain Controller 2. Verify DNS Client Settings

Verify DNS Server Configuration for a Domain Controller
You can use this procedure to verify DNS Server service configuration on a new additional domain controller that has Domain Name System (DNS) installed. Verify that resource records are registered so that clients can locate the DNS server. Verify also that the forest and domain DNS zone application directory partitions have replicated so that the DNS server receives zone updates.

409

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify DNS server configuration for a domain controller 1. Open the DNS snap-in: On the Start menu, point to Administrative Tools, and then click DNS. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. Double-click Forward Lookup Zones, and verify that the zone _msdcs.ForestRootDomain and the zone for the domain of the new domain controller are present. 3. Click the domain node, and then, in the details pane, verify that host (A) resource records, IPv6 host (AAAA) resource records (if TCP/IPv6 addresses are in use), and name server (NS) resource records are present for the new domain controller. 4. To verify that the ForestDnsZones and DomainDnsZones application directory partitions replicated successfully, open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 5. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl

6. Verify that the DC=DomainDnsZones,DC=DomainName, …,DC=ForestRootDomainName,DC=com and DC=ForestDnsZones,DC=ForestRootDomainName,DC=com application directory partitions replicated successfully.

See Also
Verify DNS Client Settings

Verify DNS Client Settings
After you install an additional domain controller, verify the DNS Client service settings on the new domain controller. If you use the Active Directory Domain Services Installation Wizard to install a domain controller, the wizard configures the DNS Client service settings, as follows: • The preferred Domain Name System (DNS) server is added to the DNS servers list of the DNS client settings. • The alternate DNS server is unchanged, but 127.0.0.1 is added.

410

Note If IP version 6 (IPv6) is enabled, IPv6 addresses are used instead of IP version 4 (IPv4) addresses. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify the DNS client settings 1. In Server Manager, click View Network Connections. 2. Right-click the connection that represents the connection that the domain controller uses to attach to the network, and then click Properties. 3. In Connection Properties, double-click Internet Protocol Version 4 (TCP/IPv4) or Internet Protocol Version 6 (TCP/IPv6). 4. In Internet Protocol (TCP/IP) Properties, verify that Use the following DNS server addresses is selected. 5. Verify that the Preferred DNS server IP address is the IP address of the new domain controller (so that it is referencing itself). Verify that the Alternate DNS server address is that of another DNS server in the same domain. 6. Click OK twice.

See Also
Verify DNS Server Configuration for a Domain Controller

Check the Status of the SYSVOL and Netlogon Shares
You can use this procedure to make sure that the Distributed File System (DFS) Replication service is started properly and then ensure that the sysvol shared folder and netlogon (scripts) shared folder are created and shared. For information about checking SYSVOL status for File Replication Service (FRS), see the Windows Server 2003 topic Check the status of the shared SYSVOL (http://go.microsoft.com/fwlink/?LinkId=120774). Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To check the status of the SYSVOL and Netlogon shares 1. On the Start menu, point to Administrative Tools, and then click Services. 411

2. Verify that the DFS Replication service and the Netlogon service have a status of Started. If a service is stopped, click Restart. 3. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 4. To verify that the SYSVOL tree includes the sysvol and scripts shared folders, at the command prompt, type the following command, and then press ENTER:
net share

5. Check the list to be sure that it includes %systemroot%\SYSVOL\sysvol\ (the SYSVOL share) and %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS (the NETLOGON share), where <Domain Name> is the domain of the new domain controller. Note If neither %systemroot%\SYSVOL\sysvol\ nor %systemroot%\SYSVOL\sysvol\<Domain Name>\SCRIPTS are present, see Verify Active Directory Replication. 6. Verify that the proper permissions are set for SYSVOL replication. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:netlogons

Look for a message that states that <ComputerName> passed test NetLogons, where <ComputerName> is the name of the domain controller. If you do not see the “passed test” message, check the permissions that are set on the Scripts and Sysvol shared folders. For information about default SYSVOL permissions, see Reapply Default SYSVOL Security Settings.

Verify Active Directory Replication
You can use this procedure to verify that Active Directory replication is functioning properly on a domain controller. Membership in Domain Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify Active Directory replication 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER: 412

dcdiag /test:replications

Note For more detailed replication information, use the /v option. If this test fails, open Event Viewer and check for errors in the Directory Service log. Use the information in the ActiveDirectory_DomainService replication events to troubleshoot the problem.

Verify a Domain Computer Account for a New Domain Controller
You can use this procedure to verify that a domain computer account is registered properly and that the Service Principal Names (SPNs) are advertised. This account is required for the domain controller to function as a domain controller in the domain. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify a domain computer account for a new domain controller 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:MachineAccount

3. It the test is successful, you should see the following message:
<ComputerName> passed test MachineAccount.

To receive more detailed information, including the SPNs that are found for the domain controller, use the /v option.

Adding Domain Controllers in Remote Sites
You can create an additional domain controller in a domain by installing Active Directory Domain Services (AD DS) on a server computer. When you are placing the additional domain controller in a remote site, you can install AD DS on the server either before or after you ship it to the remote site, as follows: 413

• Ship the computer as a workgroup computer, and install AD DS on it in the remote site. If you do not have administrative support in the remote site, enable Remote Desktop on the computer before you ship the computer so that you can perform the installation remotely. In the remote site, you can either: • Install AD DS from installation media that has been shipped to the site on removable media. • Install AD DS over the network. • Install AD DS on the server in a hub or staging site, and then 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 removable media. For information about the advantages and disadvantages of shipping a server to a remote site before or after installing AD DS, see Known Issues for Adding Domain Controllers in Remote Sites. For recommended practices for adding domain controllers to remote sites for the method that you are using, see Best Practices for Adding Domain Controllers in Remote Sites. By reviewing issues and guidelines, you can decide the best method of adding domain controllers in remote sites for your environment. By following the instructions in this guide, you can safely and securely install domain controllers in remote sites, either locally or remotely. Note On servers that are running Windows Server 2008, you can install a read-only domain controller (RODC), which is ideal for providing AD DS in remote sites without incurring the security risks of a writable domain controller. For information about installing and managing RODCs in remote sites, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkID=120709). This section includes the following tasks, known issues, and best practices for adding domain controllers in remote sites: • • • • • Known Issues for Adding Domain Controllers in Remote Sites Best Practices for Adding Domain Controllers in Remote Sites Preparing a Server Computer for Shipping and Installation from 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 Active Directory Domain Services (AD DS) to create domain controllers in your remote sites. The following best practices help ensure trouble-free installation of domain controllers in remote sites. 414

Important Do not attempt to perform actions based only on the recommendations that are described in this topic. Step-by-step guidance is provided in the task-based topics in this guide for all recommendations in this topic.

Best practices for using IFM to install AD DS in the remote site
Installation from media (IFM) is a method of installing AD DS without replication from a source domain controller. By using IFM, you provide a local source for the domain, configuration, and schema directory partitions—and, as an option, global catalog, partial, read-only directory partitions and Domain Name System (DNS) application directory partitions. The local source is the installation media files that reside on the server that you are installing. Updates to object attributes that occur since the installation media was created will replicate over the network from an existing domain controller in the domain or forest. Although SYSVOL is part of the installation media, under normal conditions the source for SYSVOL is not the installation media. Instead, SYSVOL is created by replication from an existing domain controller. Configuring the installation media to be the source for SYSVOL requires additional procedures. For information about using installation media as the source for SYSVOL during IFM installation of AD DS, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840). To use IFM for installation of one or more additional domain controllers in a domain, you can do one of the following: • Specify a volume on the installation computer as the location for the media when you run the ntdsutil ifm command. For information about the effects of the location on the installation process, see Preparing a Server Computer for Shipping and Installation from Media. • Create the media locally, and then copy ("burn") the installation media onto removable media, such as a portable disk drive, CD, or DVD, which can be shipped with the installation computer when it leaves the staging site, or it can be shipped separately. • Create the media locally, and then transfer the installation media 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 Media. The following best practices optimize data security and consistency when you add domain controllers in remote sites: • Upgrade to Windows Server 2008. Windows Server 2008 includes an enhanced version of Ntdsutil.exe that you can use to create installation media, rather than using a restored system state backup as is required in Windows Server 2003. Ntdsutil.exe in Windows Server 2008 includes a new ifm command that creates installation media for additional domain controllers. The installation media that is created by this command contains only is the items that are required for installing AD DS: the Ntds.dit database file and the registry. You can create media for a full (writable) installation of AD DS or for a read-only domain controller (RODC) installation. For the RODC installation, the ntdsutil ifm command 415

creates secure installation media by removing secrets, such as passwords, from the Active Directory data. You create the media by using Volume Shadow Copy Service (VSS), taking a fraction of the time that is required to create a backup. For information about upgrading the forest to Windows Server 2008, see the AD DS Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=116283). Note On a domain controller that is running Windows Server 2008, you cannot restore a system state backup to an alternate location. Instead, use the ntdsutil ifm command to create installation media. • Create media on the type of domain controller that you want to add. You must create installation media on the type of domain controller that you want to add. If you want to add a global catalog server in the remote site, run the ntdsutil ifm command on a global catalog server in the domain. If you want to add a DNS server, run the ntdsutil ifm command on a domain controller that is a DNS server in the domain. • Take the same security precautions when you ship removable installation media—or a server computer that contains installation media—as you would when you ship an installed domain controller. For information about securing domain controllers, see the Best Practice Guide for Securing Windows Server Active Directory Installations (http://go.microsoft.com/fwlink/?LinkId=28521). • Minimize the time between media creation and installation. Minimizing this delay reduces the number of updates that will be required to replicate after installation. • Install the operating system before you ship 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 the number of domains in the forest can aid attackers in their attempts to compromise or steal directory data. • Ship computers with properly configured IP, subnet mask, default gateway, and DNS server addresses. Remember to reconfigure the server with TCP/IP settings that are appropriate to the target site, not the staging site. • Enable Remote Desktop on the server computer before shipping. This best practice assumes that you want to install and manage AD DS remotely rather than employing an administrator with Domain Admins credentials in each remote site.

416

Best practices for installing domain controllers before you ship them to a remote site
When you install AD DS 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, they 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 help ensure a smooth and secure disconnection and restart. For stepby-step procedures to perform all of these best practices, see Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection and Reconnecting a Domain Controller After a Long-Term Disconnection. • Configure the tombstone lifetime appropriately. Ensure that the tombstone lifetime is not lowered below the default value. The default tombstone lifetime in a forest that is created on a domain controller running Windows 2000 Server or Windows Server 2003 is 60 days. The default tombstone lifetime in a forest that is created on a server running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008 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 disconnected safely. 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 be disconnected safely, without danger of expired deletions (tombstones) remaining on the domain controller. • 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. 417

• Ensure that strict replication consistency is enabled on all domain controllers. Strict replication consistency is a registry setting that—when it is enabled—stops inbound replication of a directory partition from a source domain controller that is suspected of having a lingering object. Strict replication consistency should be enabled for the forest to prevent the reintroduction of a lingering object into the directory. You can use the repadmin /regkey command to enable this setting on a specific domain controller or on all domain controllers in the forest, as described in Enable Strict Replication Consistency. • 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, default gateway, and DNS server addresses. Remember to reconfigure the server with TCP/IP settings that are appropriate to the target site, not the staging site. • Prepare the registry for automatic nonauthoritative restore of SYSVOL when the domain controller restarts. This recommendation applies only when you use FRS to replicate SYSVOL. For FRS replication of SYSVOL, the nonauthoritative restore prevents the domain controller from having to reconcile and process deletions and modifications that took place from the time of the last SYSVOL update to the time that the domain controller is restarted in the new site, which improves synchronization time. For information about preparing for nonauthoritative restore of SYSVOL, see Prepare a domain controller for nonauthoritative SYSVOL restart (http://go.microsoft.com/fwlink/?LinkId=122831). This additional configuration is not required for Distributed File System (DFS) Replication of SYSVOL because DFS Replication processes updates differently. • 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, update 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. • 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 ensure that the domain controller uses the domain hierarchy to synchronize time: 418

w32tm /resync/ computer:<PDCEmulatorHostName>

See Also
Known Issues for Adding Domain Controllers in Remote Sites Preparing a Server Computer for Shipping and Installation from 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
Review the following known issues before adding domain controllers in remote sites. 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. Each method has advantages and disadvantages that are described in this section. Important Do not attempt to perform actions based only on the recommendations in this topic. Stepby-step guidance is provided in the task-based topics in this section for all actions that are recommended in this topic. Follow the links in this topic to the related task-based topics. You can use the following methods to add domain controllers in remote sites: • Ship the member computer to the remote site, and then use the install from media (IFM) method to install Active Directory Domain Services (AD DS) on that computer. IFM uses previously prepared installation media as the source for the installation of AD DS in the remote site, avoiding replication from a source domain controller. • Install AD DS in the hub site by using the normal Dcpromo method or the IFM method, and then ship the installed domain controller to the remote site. SYSVOL replication issues potentially affect both methods.

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 Net Logon scripts, Group Policy settings, and either File Replication Service (FRS) or Distributed File System (DFS) Replication staging directories and files, depending on the replication method in use for replicating DFS folders. Replication of the SYSVOL folder is required for AD DS to function properly. The primary focus for both methods of installing additional domain controllers in remote sites is to avoid the replication of AD DS 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. When you use 419

the IFM method to install a domain controller, SYSVOL is replicated from a domain controller in the domain unless you perform preliminary procedures. For information about using installation media as the source for SYSVOL during IFM installation of AD DS when you use DFS Replication to replicate SYSVOL, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840). If you use FRS to replicate SYSVOL, see article 311078 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=70809).

Using IFM to install a domain controller in a remote site
On domain controllers that are running Windows Server 2008, the Ntdsutil command-line tool is improved to include a new command for creating installation media. The method for using IFM to install domain controllers includes the following general steps: 1. Use the Ntdsutil ifm command to create installation media from an up-to-date domain controller in the domain. If you want the additional domain controller to be a global catalog server, create the media on a global catalog server. If you want the additional domain controller to be a Domain Name System (DNS) server, create the media on a DNS server. 2. When you create additional domain controllers in the domain, you can refer to the shared folder or removable media where you store the installation media as follows: on the Install from Media page in the Active Directory Domain Services Installation Wizard or by using the /ReplicationSourcePath parameter during an unattended installation. As an alternative, you can create installation media by using Wbadmin.exe to restore a criticalvolumes backup to an alternate location. However, the Ntdsutil method is more efficient because you eliminate the restore process, which adds time and effort to the installation process. Note In Windows Server 2008, you cannot restore a system state backup to a network shared folder.

Advantages of using IFM to install a domain controller in a remote site
The following advantages are associated with using IFM to install a domain controller in a remote site: • You can install many domain controllers from a single source of installation media. • You do not have to disconnect a functioning 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 AD DS over a WAN link, particularly a link that requires a dial-up connection.

420

• 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. You can also use Remote Server Administration Tools (RSAT) to manage AD DS remotely. You can install the tools on a member server that is running Windows Server 2008 or on a workstation that is running Windows Vista with Service Pack 1 (SP1). For information about installing these tools, see Installing Remote Server Administration Tools for AD DS. Note If you do not need a writable domain controller in a remote site, you can install a readonly domain controller (RODC) in the remote site. RODCs do not require administrative credentials for management. For information about using RODCs in remote sites, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkID=120709).

Issues with using IFM to install a domain controller in a remote site
The following issues are associated with using IFM to install a writable domain controller in a remote site: • Domain Admins credentials and remote installation. If you install a writable domain controller, an administrator must have Domain Admins credentials to install AD DS. 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 enable Remote Desktop on the server before you ship it to the remote site. • Bridgehead server load balancing. If installation 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 SYSVOL replication. Note These issues are of concern only in situations in which hundreds of domain controllers might be promoted at the same time and FRS is the SYSVOL replication system. If you are deploying hundreds of writable domain controllers in branch sites, see the Windows Server 2003 Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?LinkId=42506). If you are installing RODCs in branch sites, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkID=120840). • SYSVOL replication. Whether you use DFS Replication or FRS to replicate SYSVOL, replication of the full SYSVOL occurs if you do not perform preliminary preseeding procedures, as described in article 311078 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=70809) for SYSVOL that is replicated by FRS, and in Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/? LinkId=120840) for SYSVOL that is replicated by DFS Replication. When you install AD DS 421

without this additional preparation, the SYSVOL data in the installation media is deleted and SYSVOL is generated by 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 for a single 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. Note When you use DFS Replication to replicate SYSVOL, these conditions are not an issue. For information about performing a staged installation of RODCs, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/?LinkId=120840).

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 activities of other domain controllers on the network. This interruption 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 you ship 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 in this guide 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 limited to the hub 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:

422

• Disconnection error conditions. After disconnection, online domain controllers in the domain continue to attempt replication with the disconnected domain controller, causing AD DS and SYSVOL replication 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. To avoid full replication of SYSVOL, you can take steps to ensure that only SYSVOL updates are replicated when the domain controller starts in the branch site. • 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 AD DS on all connected domain controllers. Deletion updates are replicated as tombstone objects. These objects have a limited lifetime in AD DS, which is defined by the tombstone lifetime. After a tombstone is permanently removed from Active Directory, replication of the deletion that 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 the object remains in AD DS 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. Caution The default value for the tombstone lifetime is 180 days. In this case, the risk is remote if the tombstone lifetime is not changed. However, because the tombstone lifetime value can be changed administratively and because the risk has such significant consequences, you should always check the tombstone lifetime setting. For more information about lingering objects and their causes and effects, see Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042) (http://go.microsoft.com/fwlink/?LinkId=120797).

Maintaining directory consistency when you disconnect a domain controller
Maintaining consistency of Active Directory data involves several related issues. Review the following known issues before you disconnect an installed domain controller: • • Protection against lingering object replication Availability of operations master roles in the domain and forest 423

• • • •

Up to dateness of Active Directory replication at the time of disconnection SYSVOL consistency at reconnection Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection Reconnecting a Domain Controller After a Long-Term Disconnection

For procedures to ensure that all of these issues are resolved, see the following topics:

Protection against lingering object replication
Domain controllers that have not performed inbound replication in the number of days equal to the previous tombstone lifetime 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 AD DS, 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. 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 domain controller. Replication of the directory partition is stopped 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 that it has previously deleted and permanently removed through garbage collection. The default value of the strict replication consistency registry entry is 1 on domain controllers that are running Windows Server 2003, Windows Server 2003 R2, and Windows Server 2008. If you are in doubt as to whether strict replication consistency is in effect, you can use the Repadmin command-line tool to set replication consistency to Strict for all domain controllers in the forest. If you have domain controllers that are running Windows Server 2000, update these domain controllers to Windows Server 2008.

Availability of operations masters
If you disconnect a domain controller from the network, you must ensure that it is not holding any operations master roles for the domain or forest. Check the domain controller for any operations master roles and, if you find any, transfer the roles before you disconnect the domain controller.

424

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
When you use DFS Replication for SYSVOL replication, when you restart the domain controller in the new site DFS Replication updates SYSVOL by processing the latest changes from the source domain controller. To ensure that SYSVOL is updated as quickly as possible, time the restart of the domain controller with the intersite replication schedule. When you use FRS for SYSVOL replication, in addition to timing restart according to the replication schedule preparation might be necessary to avoid an extended period of latency when SYSVOL is updated. When you restart a domain controller without this preparation, FRS reconciles and processes all deletions and modifications that took place from the time of the last SYSVOL update to the time that the domain controller is restarted in the new site. If you have a large SYSVOL, you can avoid this extra processing and replication time by preparing the domain controller for nonauthoritative SYSVOL restore before you ship the domain controller. For information about preparing the domain controller for nonauthoritative SYSVOL restore, see Prepare a domain controller for nonauthoritative SYSVOL restart (http://go.microsoft.com/fwlink/?LinkID=122831).

See Also
Preparing a Server Computer for Shipping and Installation from Media Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection Reconnecting a Domain Controller After a Long-Term Disconnection

Preparing a Server Computer for Shipping and Installation from Media
The specific guidelines for installing Active Directory Domain Services (AD DS) from installation media are provided in the topic Installing an Additional Domain Controller by Using IFM. Be sure to read that topic before you perform the procedures that are specified in this section. To prepare for an IFM installation, perform the following tasks: • Determine the type of domain controller that you want to install. Identify a domain controller that is suitable for creating the media according to whether you are creating an additional domain controller that is a global catalog server, a Domain Name System (DNS) server, both, or neither. You must create the installation media on the same type of domain controller that you want to create. 425

• Determine whether to create the installation media in a shared folder on the computer that will be installed or use removable media to ship the installation media separately from the computer. If you will create the media in a shared folder on the installation server, do the following: • Determine the volume on which to create the media. See the criteria in “Determine the volume for installation media” in this topic. • Create a shared folder on the server and map a network drive to the folder on the domain controller that you are using to create the media. • Install the operating system on the server computer. This task is best performed in the hub site where administrative personnel are available. • Enable Remote Desktop on the server before you ship it. • If you want to include application directory partitions on the domain controller, prepare an answer file that contains the location of the installation media and the application directory partitions. • Determine the volume on which to store the installation media on the installation server. This location affects SYSVOL replication after the installation of AD DS.

Determining the volume for installation media
The volume on which you store the installation media has implications for SYSVOL files. If you plan to perform additional, preliminary procedures to ensure that the installation media is the source for SYSVOL on the installation server, the installation media must be stored on the same volume that you specify during Active Directory installation to host the SYSVOL tree. If you do not store the installation media on the volume where SYSVOL is to be hosted, SYSVOL is replicated to the new domain controller, regardless of whether you perform the additional, preliminary procedures. Use the following references for information about ensuring that SYSVOL is not replicated during IFM: • For information about how to ensure that the installation media is used as the source for SYSVOL when you are using FRS to replicate SYSVOL, see "Seeding the SYSVOL tree from restored files during IFM promotion" in article 311078 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=70809). • For information about how to ensure that the installation media is used as the source for SYSVOL when you are using Distributed File System (DFS) Replication to replicate SYSVOL, see Planning and Deploying Read-Only Domain Controllers (http://go.microsoft.com/fwlink/? LinkId=120840). To assess the effect of SYSVOL replication, as opposed to additional configuration that is required to ensure that the installation media is used as the source for SYSVOL, test both processes in a lab environment that mirrors your production environment in terms of wide area network (WAN) speed and replication latency.

426

Note We recommend that you deploy at least two domain controllers in each domain for the purposes of redundancy and failover.

Enabling Remote Desktop
You can use Remote Desktop to connect to the domain controller and manage it remotely. Remote Desktop is disabled by default in Windows Server 2008. To install AD DS, you must have Domain Admins credentials in the domain into which you are adding the domain controller. This level of service administration may not be available in the remote site. In any case, you will probably want to be able to install and manage the domain controller from the hub site.

Including application directory partitions
If you want application directory partitions to be included in the installation, you must use an answer file to perform the IFM installation and include the /ApplicationPartitionsToReplicate parameter in the answer file. When you perform an unattended installation, Dcpromo uses the answer file for installation instructions, including the location of installation media and application directory partitions. Task requirements The following tools are required to complete this task: • • • Ntdsutil.exe System Control Panel Dcpromo.exe

To complete this task, perform the following procedures: 1. Create Installation Media by Using Ntdsutil. Before you perform this procedure, see Installing an Additional Domain Controller by Using IFM. Perform this procedure on a domain controller that is the type of domain controller that you want to create (for example, a global catalog server or a DNS server). Specify removable media or a shared folder on the installation server as the location for the installation media. 2. Enable Remote Desktop on the installation server. 3. Ship the installation server and any prepared removable media and answer file to the remote site. Ship these items separately and securely. When the server is running in the remote site, install the domain controller as follows: 1. Create a Remote Desktop Connection to the remote server. 2. Install an Additional Domain Controller by Using Installation Media. When the domain controller restarts after installation, the Remote Desktop Connection is dropped. After the installed domain controller restarts, you must reconnect by using Remote Desktop Connection.

427

See Also
Installing an Additional Domain Controller by Using IFM

Enable Remote Desktop
You can use this procedure to 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 2008. You can enable Remote Desktop on the Windows Server 2008 server directly, or you can enable it remotely from another server or workstation computer. Membership in local Administrators, or equivalent, is the minimum required to complete these procedures if Active Directory Domain Services (AD DS) is not installed. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure if AD DS is installed. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To enable Remote Desktop locally by using Server Manager 1. Open Server Manager. To open Server Manager, click Start, point to Administrative Tools, and then click Server Manager. 2. In Computer Information, click Configure Remote Desktop. 3. In the System Properties dialog box, under Remote Desktop, click one of the following options: • Allow connections from computers running any version of Remote Desktop (less secure). Use this option if you do not know the version of Remote Desktop Connection that will be used to connect to this server. • Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure). Use this option if you know that the users who will connect to this server are running Windows Vista or Windows Server 2008. 4. Review the information in the Remote Desktop dialog box, and then click OK twice. To enable Remote Desktop remotely by using the registry 1. On any computer that is running a version of Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows XP Professional, or Windows Vista, open Regedit as an administrator. To open Regedit as an administrator, click Start, and then, in Start Search, type regedit. At the top of the Start menu, right-click regedit, and then click Run as administrator. In the User Account Control dialog box, provide Domain Admins credentials, and then click OK. 2. On the File menu, click Connect Network Registry. 428

3. In the Select Computer dialog box, under Enter the object name to select, type the computer name, and then click Check Names. 4. After the computer name resolves, click OK. 5. In the computer node that appears in the Registry Editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server. 6. In the console tree, click Terminal Server, and then, in the details pane, double-click fDenyTSConnections. 7. In the Edit DWORD Value box, in Value data, type 0, and then click OK. This value enables connections at the level that allows connections from computers running any version of Remote Desktop. 8. To implement the change, restart the server remotely, as follows: • Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. In the User Account Control dialog box, provide Domain Admins credentials, and then click OK. • At the command prompt, type the following command, and then press ENTER:

shutdown /m \\<DomainControllerName> /r

Value

Description

/m \\<DomainControllerName> /r

The name of the computer to be shut down or restarted. Shuts down and then restarts the computer.

Create a Remote Desktop Connection
If Remote Desktop is enabled on a server, you can use this procedure to create a new Remote Desktop Connection to connect to the server and manage it remotely. Remote Desktop is disabled by default in Windows Server 2003, Windows Server 2003 R2, and Windows Server 2008 operating systems. Membership in Remote Desktop Users, or equivalent, is the minimum required to complete this procedure. If the remote computer is a domain controller, you must have the Allow Logon Locally right applied in the Default Domain Controllers Policy. Members of Account Operators, Administrators, Enterprise Admins, Domain Admins, Backup Operators, Print Operators, and Server Operators have the user right to log on locally to a domain controller by default. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

429

To create a new Remote Desktop Connection 1. On the Start menu, point to Programs or All Programs, click Accessories, and then click Remote Desktop Connection. 2. In Computer, type a computer name or IP address, and then click Connect. 3. In the Windows Security dialog box, type your password, and then click OK. If you are not logged on with an account that is a member of the Remote Desktop Users, or equivalent, click Use another account, and then provide credentials for the appropriate account.

See Also
Enable Remote Desktop

Install an Additional Domain Controller by Using Installation Media
You can use this procedure to install Active Directory Domain Services (AD DS) from media. You can use the install from media (IFM) method to create an additional domain controller in an existing domain. When you create an additional domain controller in the domain, you can specify sourcing the installation from the shared folder or removable media where you created the installation media by using one of the following methods: • Windows interface: Provide the location on the Install from Media page in the Active Directory Domain Services Installation Wizard. • Unattended installation: Use the /ReplicationSourcePath parameter in the answer file for an unattended installation. • Command line: Use the /ReplicationSourcePath unattend parameter at the command line. Membership in the Domain Admins group in the domain into which you are installing the additional domain controller, or the equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To install AD DS from IFM media by using the Windows interface 1. Use the procedure Install an Additional Domain Controller by Using the Windows Interface. In step 8, select Use advanced mode installation. 2. In step 15, select the install from media option and provide the location of the installation media. 3. Complete the remaining pages of the Active Directory Domain Services Installation 430

Wizard. 4. After the installation operation completes successfully and the computer is restarted, remove the folder that contains the IFM media from the local disk. To install AD DS from IFM media by using an answer file 1. Create an answer file by using one of the following methods: • During the procedure Install an Additional Domain Controller by Using the Windows Interface, select the Export settings option to save the installation settings to a file. This file is an answer file that you can use to install an additional domain controller in the same domain. • Use the procedure Create an Answer File for Unattended Domain Controller Installation to create an answer file. Include the /ReplicationSourcePath parameter to specify the location of the IFM media. 2. Use the procedure Install an Additional Domain Controller by Using an Answer File to install AD DS. To install AD DS from IFM media by using unattend parameters from the command line 1. Use the procedure Install an Additional Domain Controller by Using Unattend Parameters from the Command Line to install AD DS. 2. During the procedure, use the /ReplicationSourcePath parameter to specify the location of the IFM media.

See Also
Preparing for Active Directory Installation Verifying Active Directory 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 431

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. Task requirements The following tools are required to perform the procedures for this task: • • • • • • ADSI Edit Ntdsutil.exe Active Directory Users and Computers Active Directory Schema Active Directory Domains and Trusts Repadmin.exe

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 safedisconnection 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 preparations for 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. If you use File Replication Service (FRS) to replicate SYSVOL, you can decrease the time required to update SYSVOL when the domain controller is restarted by performing a preliminary registry update on the server. For instructions, see Prepare a domain controller for nonauthoritative SYSVOL restart (http://go.microsoft.com/fwlink/?LinkID=122831). This procedure is not necessary if you use Distributed File System (DFS) Replication. 9. Enable Strict Replication Consistency, if necessary. If strict replication consistency is not enabled on the domain controller that you are disconnecting, use this command-line procedure to enable strict replication consistency on specific domain controllers or on all domain controllers in the forest. 432

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 safedisconnection period.

See Also
Known Issues for Adding Domain Controllers in Remote Sites Managing Operations Master Roles Managing DFS-Replicated SYSVOL Reconnecting a Domain Controller After a Long-Term Disconnection

Determine the Tombstone Lifetime for the Forest
The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition. You can use this procedure to determine the tombstone lifetime for the forest. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the tombstone lifetime for the forest 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 2. In ADSI Edit, right-click ADSI Edit, and then click Connect to. 3. For Connection Point, click Select a well known Naming Context, and then click Configuration. 4. If you want to connect to a different domain controller, for Computer, click Select or type a domain or server: (Server | Domain [:port]). Provide the server name or the domain name and Lightweight Directory Access Protocol (LDAP) port (389), and then click OK. 5. Double-click Configuration, CN=Configuration,DC=ForestRootDomainName, CN=Services, and CN=Windows NT. 6. Right-click CN=Directory Service, and then click Properties. 7. In the Attribute column, click tombstoneLifetime. 433

8. 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), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008, 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.

Enable Strict Replication Consistency
You can use this procedure to ensure that strict replication consistency is enabled in the forest. This setting prohibits replication of outdated Active Directory objects. If you disconnect a domain controller from the replication topology for an extended period and then reconnect it, this setting ensures that no outdated objects are reintroduced into Active Directory Domain Services (AD DS). To determine whether strict replication consistency is enabled, use the regedit command to view the registry on a domain controller. 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 or Windows Server 2008 forest; otherwise 0. • Data type: REG_DWORD If the value is 0, use the following procedure to change the value to 1 on a specific domain controller or on all domain controllers. Membership in the Domain Admins group in the domain, or equivalent, is the minimum required to complete this procedure on a single domain controller. Membership in the Enterprise Admins group in the forest, or equivalent, is the minimum required to complete this procedure on all domain controllers. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To enable strict replication consistency 1. Open a command prompt, type the following command, and then press ENTER:
repadmin /regkey <DC_LIST> {+|-}<key>

434

Value

Description

repadmin /regkey

Enables and disables the values for the following two registry entries under HKEY_LOCAL_MACHINE\SYSTEM\Current Control Set\Services\NTDS\Parameters: • Strict replication consistency • Allow replication with divergent and corrupt partner

<DC_LIST>

The name of a single domain controller. Or, use * to apply 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. Membership in Enterprise Admins in the forest or Domain Admins in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To synchronize replication with all partners 1. At a command prompt, type the following command, and then press ENTER:
repadmin /syncall <DomainControllerName> /e /d /A /P /q

435

Value

Description

repadmin /syncall <DomainControllerName>

Synchronizes a specified domain controller with all replication partners. The Domain Name System (DNS) name of the domain controller on which you want to synchronize replication with all partners. Enterprise; includes partners in all sites. Identifies servers by their distinguished names 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

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 (the 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.

436

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, you can perform a procedure to safely remove lingering objects. If the disconnected domain controller is running Windows Server 2003 or Windows Server 2008 and an authoritative domain controller running Windows Server 2003 or Windows Server 2008 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 following conditions require using a different method of remove lingering objects: • The disconnected domain controller is running Windows Server 2003 or Windows Server 2008, but no other authoritative domain controller running Windows Server 2003 or Windows Server 2008 is available in the domain: Reconnect the domain controller, and follow the instructions in article 314282 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=119208). • 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 in the Microsoft Knowledge Base (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.

Updating SYSVOL
To update SYSVOL as soon as possible after you reconnect 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 you restart the domain controller. Important If you use File Replication Service (FRS) to replicate SYSVOL, the recommended practice to reduce the time required to update SYSVOL is to modify the registry before you disconnect the domain controller so that SYSVOL is updated with only the latest file changes when you restart the domain controller. For information about preparing for SYSVOL replication when using FRS, see Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection (http://go.microsoft.com/fwlink/?LinkId=122834). 437

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

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: • Move a Server Object to a New Site If the server object for the domain controller is still in the site where the domain controller was installed, move the server object to the site in which you are reconnecting the domain controller. • 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. Verify Successful Replication to a Domain Controller After replication is complete, verify replication of the domain, configuration, and schema directory partitions. If the domain controller is a global catalog server, verify replication of all domain directory partitions. If the domain controller is a Domain Name System (DNS) server, verify replication of the domain and forest DNS application directory partitions.

See Also
Preparing an Existing Domain Controller for Shipping and Long-Term Disconnection 438

Determine the Tombstone Lifetime for the Forest
The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition. You can use this procedure to determine the tombstone lifetime for the forest. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the tombstone lifetime for the forest 1. Click Start, point to Administrative Tools, and then click ADSI Edit. 2. In ADSI Edit, right-click ADSI Edit, and then click Connect to. 3. For Connection Point, click Select a well known Naming Context, and then click Configuration. 4. If you want to connect to a different domain controller, for Computer, click Select or type a domain or server: (Server | Domain [:port]). Provide the server name or the domain name and Lightweight Directory Access Protocol (LDAP) port (389), and then click OK. 5. Double-click Configuration, CN=Configuration,DC=ForestRootDomainName, CN=Services, and CN=Windows NT. 6. Right-click CN=Directory Service, and then click Properties. 7. In the Attribute column, click tombstoneLifetime. 8. 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), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008, 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.

Move a Server Object to a New Site
When you move a server object in Active Directory Domain Services (AD DS), the Active Directory Sites and Services snap-in does not require that the IP address of the server maps to the site to 439

which you are moving the server object. If the IP address does not map to a subnet that is associated with the site to which you move it, the server might be forced to communicate over a potentially slow wide area network (WAN) link to locate resources rather than locating resources in its own site. Before you move the server object, verify that the IP address maps to the target site. You can use this procedure to move a server object to a new site. Membership in Enterprise Admins, or equivalent, is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To move a server object to a new site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, expand Sites and the site in which the server object resides. 3. Expand Servers to display the domain controllers that are currently configured for that site. 4. Right-click the server object that you want to move, and then click Move. 5. In Site Name, 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 that 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 Domain Name System (DNS). Wait an hour, and then open Event Viewer and connect to the domain controller whose server object you moved. Review the System log for NETLOGON errors regarding registration of service (SRV) resource records in DNS that have occurred within the last hour. The absence of errors indicates that the Net Logon service has updated DNS with sitespecific service (SRV) resource records. NETLOGON Event ID 5774 indicates that the dynamic registration of DNS resource records has failed. If this error occurs, contact a supervisor and pursue DNS troubleshooting.

See Also
Verify That an IP Address Maps to a Subnet and Determine the Site Association

Determine When Intersite Replication Is Scheduled to Begin
Before you restart a domain controller that has been disconnected and shipped to a branch site, if the domain controller is the only domain controller for the domain in the site, the domain controller must be updated from the hub site. You can minimize the time that the domain controller is out of 440

synchronization with domain controllers in the hub site by timing the restart to coincide with intersite replication. You can use this procedure to determine when intersite replication between sites is scheduled to begin. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine when intersite replication is scheduled to begin 1. Open Active Directory Sites and Services: Click Start, point to Administrative Tools, and then click 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 SiteLinkNameProperties dialog box, click Change Schedule. Note the block of days and hours during which replication is allowed (Replication Available), and then click OK or Cancel. 5. In Replicate every _____ minutes, 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 the Repadmin tool 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) (http://go.microsoft.com/fwlink/?LinkID=120797). If you are running the procedure without having received Event ID 1388 or Event ID 1988, you must gather the following information before you begin the procedure: • The 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. • The 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. This domain controller is the source domain controller. The source domain controller and the domain controller from which you want to remove lingering objects must be 441

running a version of either Windows Server 2003 or Windows Server 2008. If either domain controller is running Windows 2000 Server, follow the instructions in article 314282 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=37924). Use the following procedure to determine the GUID of a domain controller. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine the GUID of a domain controller 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At a command prompt, type the following command, and then press ENTER:
repadmin /showrepl <DomainControllerName>

Where <DomainControllerName> is the NetBIOS name of the domain controller whose GUID you want to determine. 3. In the top portion of the output, note the value in DC
object GUID:

Use the following procedure to remove lingering objects by using Repadmin. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 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

442

Value

Description

repadmin /removelingeringobjec ts <ServerName> <ServerGUID> <DirectoryPartition>

Removes objects that have been deleted and permanently removed from replication partners but remain on this domain controller. 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=c om. 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 that 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, at a command prompt, type repadmin /listhelp, and then press ENTER.

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 443

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. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify successful replication to a domain controller 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl <servername> /u:<domainname>\<username> /pw:*

Note The user credential parameters (/u:<domainname>\<username> /pw:*) are not required for the domain of the user if the user has opened the Command Prompt as an administrator with Domain Admins credentials or is logged on to the domain controller as a member of Domain Admins or equivalent. However, if you run the command for a domain controller in a different domain in the same Command Prompt session, you must provide credentials for an account in that domain.

444

Value

Description

repadmin /showrepl

Displays the replication status for the last time that the domain controller that is named in <servername> attempted inbound replication of Active Directory partitions. The name of the destination domain controller. Specifies the domain name and user name, separated by a backslash, for a user who has permissions to perform operations in AD DS. 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.) The name of an administrative account in that domain. Specifies the domain password for the user named in <username>. * provides a Password: prompt when you press ENTER.

<servername> /u:

<domainname>

<username> /pw:*

3. At the Password: prompt, 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 Microsoft Excel 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 creates this spreadsheet and sets column headings for improved readability.

445

To generate a repadmin /showrepl spreadsheet for all replication partners 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv >showrepl.csv

3. Open Excel. 4. Click the Office button, 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. • Or • To delete the column, right-click the selected column, and then click Delete. 7. Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top Row. 8. Select the entire spreadsheet. On the Data tab, click Filter. 9. In the Last Success Time column, click the down arrow, and then click Sort Ascending. 10. In the Source DC column, click the filter down arrow, point to Text Filters, and then click Custom Filter. 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 11 for the Last Failure Time column, but use the value does not equal, and then 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 (http://go.microsoft.com/fwlink/?LinkID=93582): • • • The last successful intersite replication was before the last scheduled replication. The last intrasite replication was longer than one hour ago. Replication was never successful. To hide the column, right-click the column, and then click Hide.

446

Renaming a Domain Controller
You can use the Netdom.exe command-line tool to rename a domain controller if the domain functional level is Windows Server 2003 or Windows Server 2008. At these domain functional levels, Netdom provides the required preparation for Domain Name System (DNS) and service recognition of the new domain controller name. You can also use the System Properties user interface (UI), 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. The ability to rename domain controllers 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 it 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 effects of renaming a domain controller should be well understood before the domain controller is renamed. Although you can use System Properties 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 (or both) to the renamed domain controller. To avoid this delay, you can use the Netdom command-line tool to rename a domain controller. Task requirements The following is required to perform the procedures for this task: • • System Properties or Netdom.exe Ldp.exe or ADSI Edit

If you want to use Netdom, the domain functional level must be set to Windows Server 2003 or Windows Server 2008. 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 or DFS Replication Member Object Or 1. Rename a Domain Controller Using Netdom 447

2. Update the FRS or DFS Replication Member Object

Rename a Domain Controller Using System Properties
You can use this procedure to rename a domain controller by using the System Properties graphical user interface (GUI). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To rename a domain controller using System Properties 1. In Server Manager, click Change System Properties. 2. On the Computer Name tab, click Change. 3. Click OK to acknowledge that renaming the domain controller may cause it to become temporarily unavailable to users and computers. 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. 4. Under Computer Name, type the new name, and then click OK. 5. Click OK to close the System Properties dialog box. 6. If you are prompted, provide the user name and password for an account with Domain Admin or Enterprise Admin credentials.

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 command-line tool. The netdom command updates the Service Principal Name (SPN) attributes in Active Directory Domain Services (AD DS) for the computer account. This command also 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

448

name. If the updates and registrations have not occurred before the removal of the old computer name, some clients might not be able to locate this computer using the new name or the old name. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To rename a domain controller using Netdom 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command to add the new domain controller name, and then press ENTER:
netdom computername <CurrentComputerName> /add:<NewComputerName>

Value

Description

netdom computername <CurrentComputerName>

Manages the primary and alternate names for a computer. The current, or primary, fully qualified DNS name of the computer that you are renaming. Specifies that a new alternate DNS name should be added. The new fully qualified DNS name for the computer that you are renaming.

/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>

449

Value

Description

netdom computername <CurrentComputerName>

Manages the primary and alternate names for a computer. The current, or primary, fully qualified domain name (FQDN)of the computer that you are renaming. Specifies that an existing alternate name should be made into the primary name. The new name for the computer. The NewComputerName must be a 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 msDS-AllowedDNSSuffixes attribute of the domainDns object.

/makeprimary: <NewComputerName>

4. Restart the computer. 5. After the computer restarts, open a Command Prompt. 6. At the command prompt, type the following command to remove the old domain controller name, and then press ENTER:
netdom computername <NewComputerName> /remove:<OldComputerName>

Value

Description

netdom computername <NewComputerName> /remove: <OldComputerName>

Manages the primary and alternate names for a computer. The new FQDN that you added for the computer in step 2. Specifies that an existing alternate name should be removed. The old FQDN of the renamed computer.

See Also
Rename a Domain Controller Using System Properties 450

Update the FRS or DFS Replication Member Object
You can use this procedure to update the File Replication Service (FRS) or Distributed File System (DFS) Replication member object after you rename a domain controller. This object must be updated with the new domain controller name so that the domain controller can replicate SYSVOL. For more information about this procedure, see article 316826 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=82821). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To update the FRS member object 1. On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers. 2. On the View menu, click Advanced Features. 3. Expand the domain node, System, File Replication Service, and Domain System Volume (SYSVOL share). The <DomainControllerName> objects below Domain System Volume (SYSVOL share) are the FSR Member objects that correspond to domain controllers in the domain. Find the <DomainControllerName> object that shows the old name of the domain controller. 4. Right-click the FRS Member object for the old name of the domain controller, and then click Rename. 5. Type the new name of the domain controller. 6. To verify the name change, open ADSI Edit: On the Start menu, point to Administrative Tools, and then click ADSI Edit. View the fRSMemberReference attribute of the object CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=<DomainControllerName>,OU=Domain Controllers,DC=<DomainName> and confirm that the value in CN=<DomainControllerName> is the new name. To update the DFS Replication member object 1. On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers. 2. On the View menu, click Advanced Features. 3. Expand the domain node, System, DFSR-GlobalSettings, Domain System Volume, and Topology. The <DomainControllerName> objects below Domain System Volume are the msDFSR-Member objects that correspond to domain controllers in the domain. Find the <DomainControllerName> object that shows the old name of the domain controller. 4. Right-click the msDFSR-Member object for the old name of the domain controller, and 451

then click Rename. 5. Type the new name of the domain controller. 6. To verify the name change, open ADSI Edit: On the Start menu, point to Administrative Tools, and then click ADSI Edit. View the msDFSR-MemberReference attribute of the object CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<DomainControllerName>,OU=Domain Controllers,DC=<DomainName> and confirm that the value in CN=<DomainControllerName> is the new name.

Decommissioning a Domain Controller
Decommissioning a domain controller removes all Active Directory components and related components and returns the domain controller to a member server role. This task provides procedures for removing a domain controller from a domain that has other domain controllers.

Removing a domain or a forest
The following topics contain information about removing a domain or a forest: • To remove a domain, see Removing the Last Windows Server 2008 Domain Controller in a Domain (http://go.microsoft.com/fwlink/?LinkId=93208). • To remove a forest, see Removing the Last Windows Server 2008 Domain Controller in a Forest (http://go.microsoft.com/fwlink/?LinkId=93209).

Protecting EFS-encrypted files
If the domain controller to be decommissioned hosts any Encrypting File System (EFS)–encrypted files, you must take precautions to protect the private key for the recovery agent for the local EFSencrypted documents. This might be lost during Active Directory removal when the Security Accounts Manager (SAM) is recreated on the computer. In this case, you are unable to recover encrypted documents on this computer unless you unencrypt all the files and the recovery agent is changed to an existing domain account before re-encryption. To prevent loss of the private key, you must back up (export) the recovery agent private key before you decommission the domain controller. After you remove Active Directory Domain Services (AD DS), import the private key again. You must be able to ensure that the domain account that is serving as the recovery agent for the certificate remains the same after you remove AD DS. If you cannot guarantee that the account will remain the same after the domain controller is decommissioned or if you removed AD DS without backing up the certificate and you cannot recover EFS-encrypted files, see article 276239 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=117370). 452

Task requirements The following tools are required to perform the procedures for this task: • • • • • • Dcdiag.exe Active Directory Schema Active Directory Domains and Trusts Active Directory Users and Computers Active Directory Sites and Services Ntdsutil.exe

If you must protect the recovery agent private key for encrypted files, the following additional tool is required: • Certificates snap-in To complete this task, perform the following procedures: 1. Verify DNS Registration and TCP/IP Connectivity The Active Directory Domain Services Installation Wizard requires both TCP/IP connectivity and Domain Name System (DNS) to locate another domain controller in the domain. During the removal of AD DS, contact with other domain controllers is required to ensure the following: • • • 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 another domain controller during Active Directory removal, the decommissioning operation fails. As with the installation process, test the communication infrastructure before you run the installation wizard. Before you remove AD DS, use the same connectivity tests that you used before you installed AD DS. 2. View the Current Operations Master Role Holders To avoid problems for client computers in the domain and forest, transfer any operations master (also known as flexible single master operations or FSMO) roles before you run the Active Directory Domain Services Installation Wizard to decommission a domain controller so that you can control the operations master role placement. If you need to transfer any operations master roles from a domain controller, review all the recommendations for role placement before you perform the transfer, as described in Introduction to Administering Operations Master Roles. Identify the domain controllers to which you will transfer each role before you perform the transfer procedures. Caution During the decommissioning process, the Active Directory Domain Services Installation Wizard checks for the presence of operations master roles. If the domain controller being decommissioned holds any operations master (also known as flexible single master operations or FSMO) role, the wizard provides a warning and attempts to transfer the role or roles to another domain controller without any user interaction. You 453

do not have control over which domain controller receives the operations master roles that are transferred, and the wizard does not indicate which domain controller receives them. If the wizard cannot transfer an operations master role, you can override the warnings and the wizard will continue to uninstall AD DS and leave your domain or forest without the role. In this case, you must seize the operations master role to another domain controller. If the domain controller holds any operations master roles, use the following procedures to transfer the role or roles: Transfer the Schema Master Transfer the Domain Naming Master Transfer the Domain-Level Operations Master Roles 3. Determine Whether a Domain Controller Is a Global Catalog Server If you remove AD DS from a domain controller that hosts the global catalog, the Active Directory Domain Services Installation Wizard confirms that you want to continue with removing AD DS. This confirmation ensures that you are aware that you are removing a global catalog server 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 AD DS until you know that at least one other global catalog server is available. 4. Verify the Availability of the Operations Masters Verify that the operations master role holders are online and responding. Important If any verification test fails, do not continue until you determine the problems and fixthem. If these tests fail, the uninstallation is also likely to fail. 5. If the domain controller hosts encrypted documents, perform the following procedure before you remove AD DS to ensure that the encrypted files can be recovered after AD DS is removed: Back Up A Certificate With Its Private Key (http://go.microsoft.com/fwlink/?LinkId=122856). 6. Removing a Windows Server 2008 Domain Controller from a Domain You can remove AD DS by using the Windows interface, an answer file, or the command line. 7. If the domain controller hosts encrypted documents and you backed up the certificate and private key before you removed AD DS, perform the following procedure to import the certificate to the server again: Import a Certificate (http://go.microsoft.com/fwlink/?LinkID=108290). 8. Determine Whether a Server Object Has Child Objects 9. Delete a Server Object from a Site Note You may not want to remove the server object if it hosts something in addition to AD DS, for example, Microsoft Exchange. 454

See Also
Introduction to Administering Operations Master Roles

Verify DNS Registration and TCP/IP Connectivity
You can use the Dcdiag command-line tests in this procedure to verify that a server can successfully connect to domain controllers in the same site or in the enterprise and to verify that Domain Name System (DNS) is functioning. By default, all Dcdiag tests verify TCP/IP connectivity for both IP version 4 (IPv4) and IP version 6 (IPv6). Note Dcdiag is installed with Active Directory Domain Services (AD DS) by default. To perform this test on a server that is not a domain controller, you must install Dcdiag. For information about installing Dcdiag, see Installing Remote Server Administration Tools for AD DS. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify DNS registration and TCP/IP connectivity 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:dns

Note For a more detailed response from this command, add /v to the end of the command. If the test fails, do not attempt any additional steps until you determine and fix the problem that prevents proper DNS functionality.

View the Current Operations Master Role Holders
To view the current operations master (also known as flexible single master operations or FSMO) role holders, use the Ntdsutil.exe command-line tool with the roles option. This option displays a list of all current role holders. 455

After you transfer an operations master role, use this procedure to verify that the transfer has occurred successfully throughout the domain. To have full effect, the change must replicate to all domain controllers in the domain for a domain-level role and to all domain controllers in the forest for a forest-level role. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To view the current operations master role holders 1. Open Ntdsutil as an administrator: Click Start, and then, in Start Search, type ntdsutil. At the top of the Start menu, right-click ntdsutil, and then click Run as administrator. In the User Account Control dialog box, provide Domain Admins credentials, and then click OK. 2. At the ntdsutil: prompt, type roles, and then press ENTER. 3. At the fsmo
maintenance:

prompt, type connections, and then 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 that contains the operations masters. 5. After you receive confirmation of the connection, type quit, and then press ENTER to exit this menu. 6. At the fsmo ENTER.
maintenance:

prompt, type select

operation target,

and then press and

7. At the select operations target: prompt, type list then press ENTER.

roles for connected server,

The system responds with a list of the current roles and the Lightweight Directory Access Protocol (LDAP) name of the domain controllers that are currently assigned to host each role. 8. Type quit, and then press ENTER to exit each prompt in Ntdsutil.exe. At the ntdsutil: prompt, type quit, and then press ENTER to close the window.

Transfer the Schema Master
You can use this procedure to transfer the schema operations master role if the domain controller that currently hosts the role is inadequate, has failed, or is being decommissioned. The schema master is a forest-wide operations master (also known as flexible single master operations or FSMO) role. Before you perform this procedure, you must identify the domain controller to which you will transfer the schema operations master role.

456

Before you can use the Active Directory Schema snap-in for the first time, you must register it with the system. If you have not yet prepared the Active Directory Schema snap-in, see Install the Schema Snap-in before you begin this procedure. Note You perform this procedure by using a Microsoft Management Console (MMC) snap-in, although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, see Ntdsutil (http://go.microsoft.com/fwlink/?LinkId=120970). For information about the ntdsutil command, you can type ? at the Ntdsutil.exe command prompt. Membership in Schema Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Transfer the schema master 1. Open the Active Directory Schema snap-in. 2. In the console tree, right-click Active Directory Schema, and then click Change Active Directory Domain Controller. 3. In the Change Directory Server dialog box, under Change to, click This domain Controller or AD LDS instance. 4. In the list of domain controllers, click the name of the domain controller to which you want to transfer the schema master role, and then click OK. 5. In the console tree, right-click Active Directory Schema, and then click Operations Master. The Change Schema Master box displays the name of the server that is currently holding the schema master role. The targeted domain controller is listed in the second box. 6. Click Change. Click Yes to confirm your choice. The system confirms the operation. Click OK again to confirm that the operation succeeded. 7. Click Close to close the Change Schema Master dialog box.

Transfer the Domain Naming Master
You can use this procedure to transfer the domain naming operations master role if the domain controller that currently hosts the role is inadequate, has failed, or is being decommissioned. The domain naming master is a forest-wide operations master (also known as flexible single master operations or FSMO) role. Before you perform this procedure, you must identify the domain controller to which you will transfer the domain naming operations master role.

457

Note You perform this procedure by using a Microsoft Management Console (MMC) snap-in, although you can also transfer this role by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer operations master roles, see Ntdsutil (http://go.microsoft.com/fwlink/?LinkId=120970). For information about the ntdsutil command, you can also type ? at the Ntdsutil.exe command prompt. Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To transfer the domain naming master 1. Open Active Directory Domains and Trusts: On the Start menu, point to Administrative Tools, and then click Active Directory Domains and Trusts. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if required, and then click Continue. 2. In the console tree, right-click Active Directory Domains and Trusts, and then click Change Active Directory Domain Controller. 3. Ensure that the correct domain name is entered in Look in this domain. The available domain controllers from this domain are listed. 4. In the Name column, click the domain controller to which you want to transfer the domain naming master role, and then click OK. 5. At the top of the console tree, 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 domain controller to which you want to transfer the domain naming master 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 that the transfer took place. Click Close to close the Operations Master dialog box.

Transfer the Domain-Level Operations Master Roles
You can use this procedure to transfer the following three domain-level operations master (also known as flexible single master operations or FSMO) roles: • • • Primary domain controller (PDC) emulator operations master Relative ID (RID) operations master Infrastructure operations master 458

You might want to transfer a domain-level operations master role if the domain controller that currently hosts the role is inadequate, has failed, or is being decommissioned. You can transfer all domain roles by using the Active Directory Users and Computers snap-in. Note You perform these procedures by using a Microsoft Management Console (MMC) snap-in, although you can also transfer these roles by using Ntdsutil.exe. For information about using Ntdsutil.exe to transfer the operations master roles, see Ntdsutil (http://go.microsoft.com/fwlink/?LinkID=120970.) For information about the ntdsutil command, can also type ? at the Ntdsutil.exe command prompt. Before you perform this procedure, you must identify the domain controller to which you will transfer the operations master role. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To transfer a domain-level operations master role 1. Open Active Directory Users and Computers: On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the top of the console tree, right-click Active Directory Users and Computers, and then click Change Active Directory Domain Controller. 3. Ensure that the correct domain name is entered in Look in this domain. The available domain controllers from this domain are listed. 4. In the Name column, click the name of the domain controller to which you want to transfer the role, and then click OK. 5. At the top of the console tree, right-click Active Directory Users and Computers, and then click Operations Masters. The name of the current operations master role holder appears in the Operations master box. The name of the domain controller to which you want to transfer the role appears in the lower box. 6. Click the tab for the operations master role that 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. 7. Repeat steps 5 and 6 for each role that you want to transfer.

459

Determine Whether a Domain Controller Is a Global Catalog Server
You can use the setting on the NTDS Settings object to determine whether a domain controller is designated as a global catalog server. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure when you perform the procedure remotely by using Remote Server Administration Tools (RSAT). Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine whether a domain controller is a global catalog server 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, expand the Sites container, expand the site of the domain controller that 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 the Availability of the Operations Masters
You can use this procedure to verify that the domain controllers that hold the operations master (also known as flexible single master operations or FSMO) roles can be located and that they are online and responding. You can use the tests in this procedure before you install Active Directory Domain Services (AD DS) as well as afterward. However, if you perform this procedure before you install AD DS, you must do the following: • First, use Server Manager to add the Active Directory Domain Services server role. This part of the installation procedure installs the Dcdiag.exe command line tool. Perform this procedure after you add the server role but before you run Dcpromo.exe. • Use the /s command option to indicate the name of an existing domain controller in the domain of the new domain controller. This domain controller is required to verify the ability of the server to connect to operations master role holders in the domain and forest. You do not have to use the /s option if you perform the test in this procedure after you install AD DS. The test automatically runs on the local domain controller where you are performing the 460

test. The commands in this procedure show the /s option. If you are performing this test after you install AD DS, 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. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify the availability of the operations masters 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command to ensure that the operations masters can be located, and then press ENTER:
dcdiag /s:<DomainControllerName> /test:knowsofroleholders /v

where <DomainControllerName> is the name of an existing 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. 3. Type the following command to ensure that the operations masters are functioning properly and available on the network, and then press ENTER:
dcdiag /s:<DomainControllerName> /test:fsmocheck

where <DomainControllerName> 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 as well as other important servers, such as global catalog servers and time servers. Near the bottom of your screen, a message confirms that the test succeeded. If these tests fail, do not attempt any additional steps until you fix the problem that prevents the location of operations masters and you can verify that they are functioning properly.

Back Up a Certificate With Its Private Key
Certificates are important credentials. Their loss or corruption can cause serious harm. Such harm can come from delays in authenticating your identity to an inability to retrieve encrypted data. You can back up certificates to protect them from loss or corruption, or to move them to a different computer.

461

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic. To export a certificate with the private key 1. Open the Certificates snap-in for a user, computer, or service. 2. Do one of the following: • If you are in Logical Certificate Stores view mode, in the console tree, click Certificates. • If you are in Certificate purpose view mode, in the console tree, click Purpose. 3. In the details pane, click the certificate you want to export. 4. On the Action menu, point to All Tasks, and then click Export. 5. In the Certificate Export Wizard, click Yes, export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.) 6. Under Export File Format, select one of the available certificate file-format options. Also, do one or all of the following, if available, and then click Next. • To include all certificates in the certification path, select the Include all certificates in the certification path if possible check box. • To include all extended properties of the certificate, select Export all extended properties. • To delete the private key if the export is successful, select the Delete the private key if the export is successful check box. 7. If required, In Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next. 8. In File name, type a file name and path for the PKCS #12 file that will store the exported certificate and private key, click Next, and then click Finish. Additional considerations • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions. • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC. • Strong protection (also known as iteration count) is enabled by default in the Certificate Export Wizard when you export a certificate with its associated private key. • Strong protection is not compatible with older applications. • After the Certificate Export Wizard is finished, the certificate will remain in the certificate store in addition to being in the newly-created file. If you want to remove the certificate from the certificate store, you will need to delete it.

462

Removing a Windows Server 2008 Domain Controller from a Domain
The procedures in this section describe the methods for removing a Windows Server 2008 domain controller from a domain: • • Removing a Windows Server 2008 domain controller by using the Windows interface Removing a Windows Server 2008 domain controller by using an answer file

• Removing a Windows Server 2008 domain controller by entering unattended installation parameters at the command line

Removing a Windows Server 2008 domain controller by using the Windows interface
You can use the Active Directory Domain Services Installation Wizard to remove a domain controller from an existing domain. If the domain controller hosts any Active Directory-integrated DNS zones, the wizard removes those zones and by default also attempts to remove the DNS delegations for those zones that point to the domain controller. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain. To remove a domain controller by using the Windows interface 1. Click Start, click Run, type dcpromo, and then press ENTER. 2. In the Welcome to the Active Directory Domain Services Installation Wizard page, click Next. 3. If the domain controller is a global catalog server, a message appears to warn you about the effect of removing a global catalog server from the environment. Click OK to continue. 4. On the Delete the Domain page, make no selection, and then click Next. 5. If the domain controller has application directory partitions, on the Application Directory Partitions page, view the application directory partitions in the list, and then remove or retain application directory partitions, as follows: • If you do not want to retain any application directory partitions that are stored on the domain controller, click Next. • If you want to retain an application directory partition that an application has created on the domain controller, use the application that created the partition to remove it, and then click Refresh to update the list. 6. If the Confirm Deletion page appears, select the option to delete all application directory partitions on the domain controller, and then click Next. 7. On the Remove DNS Delegation page, verify that the Delete the DNS delegations 463

pointing to this server check box is selected and then click Next. 8. If necessary, enter administrative credentials for the server that hosts the DNS zones that contain the DNS delegation for this server and then click OK. 9. On the Administrator Password page, type and confirm a secure password for the local Administrator account, and then click Next. 10. On the Summary page, to save the settings that you selected to an answer file that you can use to automate subsequent Active Directory Domain Services (AD DS) operations, click Export settings. Type a name for your answer file, and then click Save. Review your selections, and then click Next to remove AD DS. 11. On the Completing the Active Directory Domain Services Installation Wizard page, click Finish. 12. You can either select the Reboot on completion check box to have the server restart automatically or you can restart the server to complete the AD DS removal when you are prompted to do so.

Removing a Windows Server 2008 domain controller by using an answer file
The answer file that you use to remove a domain controller in a domain where other domain controllers exist requires only Domain Admin credentials. You can also create the password for the local Administrator account for the member server. If you do not specify the password in the answer file, the administrator password is blank. Administrative credentials To perform this procedure, you must be a member of the Domain Admins group in the domain. To create an answer file for removing a domain controller 1. Open Notepad or any text editor. 2. On the first line, type [DCINSTALL], and then press ENTER. 3. Create the following entries, one entry on each line. For a complete list of parameters for removing AD DS, see Demotion Operation or type dcpromo /?:Demotion at a command line. username=<administrative account in the domain> userdomain=<domain name of administrative account> password=<password for the account in UserName> administratorpassword=<local administrator password for server> removeapplicationpartitions=yes removeDNSDelegation=yes DNSDelegationUserName=<DNS server administrative account for the DNS zone that contains the DNS delegation> 464

DNSDelegationPassword=<Password for the DNS server administrative account> 4. 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 shared folder or removable media for distribution. 5. The dcpromo command to use an answer file is the same for both removing and installing a domain controller. Use the procedure "To install a new domain controller by using an answer file" to remove the domain controller.

Removing a Windows Server 2008 domain controller by entering unattended installation parameters at the command line
The dcpromo command that you use to enter unattended installation parameters at the command line is the same for both removing and installing a domain controller. Use the procedure "To install a new domain controller by entering unattended installation parameters at the command line" to remove the domain controller, but use unattended installation options that are appropriate for removing a domain controller from an existing domain. For a complete list of parameters for removing AD DS, see Demotion Operationor type dcpromo /?:Demotion at a command line.

Import a Certificate
You should only import certificates obtained from trusted sources. Importing an unreliable certificate could compromise the security of any system component that uses the imported certificate. You can import a certificate into any logical or physical store. In most cases, you will import certificates into the Personal store or the Trusted Root Certification Authorities store, depending on whether the certificate is intended for you or if it is a root CA certificate. Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic. To import a certificate 1. Open the Certificates snap-in for a user, computer, or service. 2. In the console tree, click the logical store where you want to import the certificate. 3. On the Action menu, point to All Tasks and then click Import to start the Certificate Import Wizard. 4. Type the file name containing the certificate to be imported. (You can also click Browse and navigate to the file.) 5. If it is a PKCS #12 file, do the following: • • Type the password used to encrypt the private key. (Optional) If you want to be able to use strong private key protection, select the 465

Enable strong private key protection check box. • (Optional) If you want to back up or transport your keys at a later time, select the Mark key as exportable check box. 6. Do one of the following: • If the certificate should be automatically placed in a certificate store based on the type of certificate, click Automatically select the certificate store based on the type of certificate. • If you want to specify where the certificate is stored, select Place all certificates in the following store, click Browse, and choose the certificate store to use. Additional considerations • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions. • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC. • Enabling strong private key protection will ensure that you are prompted for a password every time the private key is used. This is useful if you want to make sure that the private key is not used without your knowledge. • The file from which you import certificates will remain intact after you have completed importing the certificates. You can use Windows Explorer to delete the file if it is no longer needed.

Determine Whether a Server Object Has Child Objects
After Active Directory Domain Services (AD DS) is properly installed on a domain controller, the server object for the domain controller has a child NTDS Settings object. Other applications that are running on domain controllers can also publish child objects. When you remove AD DS from a server, the NTDS Settings child object is removed automatically from the server object in the Servers container in Active Directory Sites and Services. Before you delete a server object from the Servers container for a site, verify that the server object has no child objects. The following conditions might result in the presence of a child object: • If an NTDS Settings object is present, it is possible that replication of the deletion has not reached the domain controller whose objects you are viewing. Check the presence of the object on another domain controller, or force replication from another domain controller in the domain. (See Force Replication Between Domain Controllers.) • If a child object other than NTDS Settings is present, another application has published the object and is using the server object. In this case, do not delete the server object. Membership in Domain Users, or equivalent, is the minimum required to complete this procedure when you perform the procedure remotely by using Remote Server Administration Tools (RSAT). 466

Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To determine whether a server object has child objects 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, expand the Sites container, and then 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 you remove a domain controller from service by uninstalling Active Directory Domain Services (AD DS), the domain controller object is removed from the domain directory partition automatically. You can check this deletion by looking in the Domain Controllers container in the Active Directory Users and Computers snap-in. The server object, which represents the domain controller in the configuration directory partition, can have child objects and is therefore not removed automatically. When no child objects are visible below the server object in Active Directory Sites and Services, you can use this procedure to remove the server object. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To delete a server object from a site 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. If the User Account Control dialog box appears, provide credentials, if required, and then click Continue. 2. In the console tree, 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 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 467

properly decommissioned. If a child object other than NTDS Settings appears below the server object that you want to delete, another application has published the object. You must contact an administrator for the application and determine the appropriate action to remove the child object. 4. Click Yes to confirm your choice.

See Also
Decommissioning a Domain Controller Forcing the Removal of a Domain Controller

Add the Certificates Snap-in to an MMC
You can use the Certificates snap-in to manage certificates for a user, computer, or service account. To switch between managing certificates for your user account, a computer, or a service, you must add separate instances of the Certificates snap-in to the console.

Adding the Certificates Snap-in to an MMC
• • • For a user account For a computer account For a service

Users or local Administrators are the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic. To add the Certificates snap-in to an MMC for a user account 1. Click Start, click Start Search, type mmc, and then press ENTER. 2. On the File menu, click Add/Remove Snap-in. 3. Under Available snap-ins, double-click Certificates, and then: • If you are logged on as an administrator, click My user account, and then click Finish. • If you are logged on as a user, Certificates automatically loads. 4. If you have no more snap-ins to add to the console, click OK. 5. To save this console, on the File menu, click Save. Additional considerations • User certificates can be managed by the user or by an administrator. Local Administrators is the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic.

468

To add the Certificates snap-in to an MMC for a computer account 1. Click Start, click Start Search, type mmc, and then press ENTER. 2. On the File menu, click Add/Remove Snap-in. 3. Under Available snap-ins, double-click Certificates 4. Select Computer account and then click Next. 5. Do one of the following: • To manage certificates for the local computer, click Local computer, and then click Finish. • To manage certificates for a remote computer, click Another computer and type the name of the computer, or click Browse to select the computer name, and then click Finish. 6. If you have no more snap-ins to add to the console, click OK. 7. To save this console, on the File menu, click Save. Additional considerations • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure. • To manage certificates for another computer, you can either create another instance of Certificates in the console, or right-click Certificates (Computer Name), and then click Connect to Another Computer. Local Administrators is the minimum group memberships required to complete this procedure. Review the details in "Additional considerations" in this topic. To add the Certificates snap-in to an MMC for a service 1. Click Start, click Start Search, type mmc, and then press ENTER. 2. On the File menu, click Add/Remove Snap-in. 3. Under Available snap-ins, double-click Certificates 4. Select Service account and then click Next. 5. Do one of the following: • To manage certificates for services on your local computer, click Local computer, and then click Next. • To manage certificates for service on a remote computer, click Another computer and type the name of the computer, or click Browse to select the computer name, and then click Next. 6. Select the service for which you are managing certificates. 7. Click Finish, and then click Close. 8. If you have no more snap-ins to add to the console, click OK. 469

9. To save this console, on the File menu, click Save. Additional considerations • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure. • To manage certificates for a service on another computer, you can either create another instance of Certificates in the console, or right-click Certificates - Service (Service Name) on Computer Name, and then click Connect to Another Computer.

Forcing the Removal of a Domain Controller
Forced removal of a domain controller from Active Directory Domain Services (AD DS) 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 AD DS in the normal way, which requires connectivity to the domain. Forced removal is not intended to replace the normal AD DS removal procedure in any way. It is equivalent to permanently disconnecting the domain controller. However, after successful metadata cleanup of a forcibly removed domain controller, you can recreate the domain controller using the same name. Note On domain controllers that are running Windows Server 2008, you can perform a forced removal of AD DS on a server that can be started only in Directory Services Restore Mode (DSRM). AD DS stores a considerable amount of metadata about a domain controller. During the normal process of uninstalling AD DS on a domain controller, this metadata is removed from AD DS through a connection to another domain controller in the domain. In a forced removal, it is assumed that there is no connectivity to the domain. Therefore, there is no attempt at metadata removal (cleanup) after a forced removal. Consequently, forced removal of AD DS from a domain controller must always be followed by the metadata cleanup procedure, which removes all references to the domain controller from the domain and forest. Forced removal should not be performed on the last domain controller in a domain. For this domain controller, you can reinstall the operating system to restore the server to network operation. If the domain controller that you are forcibly removing holds an operations master (also known as flexible single master operations or FSMO) role or roles, transfer the roles before you perform the forced removal procedure. From a healthy domain controller in the domain of the operations master role, or in the forest if the role is a forest-wide role, attempt to transfer the role to another domain controller. If you do not transfer operations master roles before you forcibly remove AD DS, the roles are transferred during the metadata cleanup process automatically. However, during metadata 470

cleanup, you do not have the option to select the domain controller to which the roles are transferred. The cleanup application makes the selection automatically. If role transfer fails during metadata cleanup, you must seize the role following the metadata cleanup procedure. For more information about transferring and seizing operations master roles, see Introduction to Administering Operations Master Roles. Task requirements The following is required to perform the procedures for this task: • • • Active Directory Sites and Services Dcpromo.exe Ntdsutil.exe or Active Directory Users and Computers

To complete this task, perform the following procedures: 1. Identify Replication Partners. Use this procedure to identify a domain controller that is a replication partner of the domain controller that you are removing. Identify a replication partner in the same site, if possible. You will connect to this domain controller when you clean up server metadata. 2. Force Domain Controller Removal 3. Clean Up Server Metadata

Identify Replication Partners
You can use this procedure to examine the connection objects for a domain controller and identify its replication partners. Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To identify replication partners 1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services. 2. In the console tree, double-click 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 then determine the site association. 4. Double-click the Servers folder to display the list of servers in that site. 5. Double-click the server object for the domain controller whose replication partners you 471

want to identify to display its NTDS Settings object. 6. Click the NTDS Settings object to display the list of connection objects in the details pane. (These objects represent inbound connections that are used for replication to the server.) The From Server column displays the names of the domain controllers that are source replication partners for the selected server object.

Force Domain Controller Removal
You can use this procedure to forcefully remove Active Directory Domain Services (AD DS) from a domain controller running Windows Server 2008. On a domain controller that is running Windows Server 2008, you can forcefully remove a domain controller even when it can be started only in Directory Services Restore Mode (DSRM). Typically, you force the removal of a domain controller only if the domain controller has no connectivity with other domain controllers. Because the domain controller cannot contact other domain controllers during the operation, the Active Directory domain and forest metadata is not updated automatically as it is when a domain controller is removed normally. Instead, you must manually update the metadata after you remove the domain controller. For information about performing metadata cleanup, see Clean Up Server Metadata. You can forcefully remove a domain controller at a command line or by using an answer file. For answer file parameters that you can use to remove AD DS, see Demotion Operation (http://go.microsoft.com/fwlink/?LinkId=120996). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To force removal of AD DS from a domain controller 1. Click Start, click Run, type the following command, and then press ENTER:
Dcpromo /forceremoval

If the domain controller hosts any operations master (also known as flexible single master operations or FSMO) roles or if it is a Domain Name System (DNS) server or a global catalog server, warnings appear that explain how the forced removal will affect the rest of the environment. After you read each warning, click Yes. To suppress the warnings in advance of the removal operation, type /demotefsmo:yes at the command prompt. If you forcefully removal AD DS from a server that hosts an operations master role, you must seize the role after the Dcpromo operation. For information about seizing an operations master role, see Seizing an operations master role. 2. On the Welcome to the Active Directory Domain Services Installation Wizard page, click Next. 3. On the Force the Removal of Active Directory Domain Services page, review the 472

information about forcing the removal of AD DS and metadata cleanup requirements, and then click Next. 4. On the Administrator Password page, type and confirm a secure password for the local Administrator account, and then click Next. 5. On the Summary page, review your selections. Click Back to change any selections, if necessary. To save the settings that you selected to an answer file that you can use to automate subsequent AD DS operations, click Export settings. Type a name for your answer file, and then click Save. When you are sure that your selections are accurate, click Next to remove AD DS. 6. You can select Reboot on completion to have the server restart automatically, or you can restart the server to complete the AD DS removal when you are prompted to do so. 7. Perform metadata cleanup, as described in Clean Up Server Metadata.

See Also
Seizing an operations master role

Clean Up Server Metadata
Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS). You perform metadata cleanup on a domain controller in the domain of the domain controller that you forcibly removed. Metadata cleanup removes data from AD DS that identifies a domain controller to the replication system. Metadata cleanup also removes File Replication Service (FRS) and Distributed File System (DFS) Replication connections and attempts to transfer or seize any operations master (also known as flexible single master operations or FSMO) roles that the retired domain controller holds. These additional processes are performed automatically. You can use this procedure to clean up server metadata for a domain controller from which you have forcibly removed AD DS. On domain controllers that are running Windows Server 2008, you can use Active Directory Users and Computers to clean up server metadata. In this procedure, deleting the computer object in the Domain Controllers organizational unit (OU) initiates the cleanup process, which proceeds automatically. You can also perform metadata cleanup by using Ntdsutil.exe, a command-line tool that is installed automatically on all domain controllers. You can perform this procedure on a domain controller that is running Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 with Service Pack 2 (SP2), Windows Server 2003 R2, or Windows Server 2008. For information about performing metadata cleanup on domain controllers that are running earlier versions of Windows Server, see “Clean up server metadata” in the Windows Server 2003 Operations Guide (http://go.microsoft.com/fwlink/?LinkId=104231). 473

You can also use a script to clean up server metadata on most Windows operating systems. For information about using this script, see Remove Active Directory Domain Controller Metadata (http://go.microsoft.com/fwlink/?LinkID=123599). Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To clean up server metadata by using Active Directory Users and Computers 1. Open Active Directory Users and Computers: On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers. 2. If you have identified replication partners in preparation for this procedure, and if you are not connected to a replication partner of the removed domain controller whose metadata you are cleaning up, right-click Active Directory Users and Computers <DomainControllerName>, and then click Change Domain Controller. Click the name of the domain controller from which you want to remove the metadata, and then click OK. 3. Expand the domain of the domain controller that you forcibly removed, and then click Domain Controllers. 4. In the details pane, right-click the computer object of the domain controller whose metadata you want to clean up, and then click Delete. 5. In the Active Directory Domain Services dialog box, click Yes to confirm the computer object deletion. 6. In the Deleting Domain Controller dialog box, select This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO), and then click Delete. 7. If the domain controller is a global catalog server, in the Delete Domain Controller dialog box, click Yes to continue with the deletion. 8. If the domain controller currently holds one or more operations master (also known as flexible single master operations or FSMO) roles, click OK to move the role or roles to the domain controller that is shown. You cannot change this domain controller. If you want to move the role to a different domain controller, you must move the role after you complete the server metadata cleanup procedure. To clean up server metadata by using Ntdsutil 1. Open a command prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
ntdsutil

3. At the ntdsutil: prompt, type the following command, and then press ENTER: 474

metadata cleanup

4. At the metadata ENTER: Or

cleanup:

prompt, type the following command, and then press

remove selected server <ServerName>

remove selected server <ServerName1> on <ServerName2>

Value

Description

ntdsutil: metadata cleanup remove selected server <ServerName> or <ServerName1>

Initiates removal of objects that refer to a decommissioned domain controller. Removes objects for a specified, decommissioned domain controller from a specified server. 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. If you specify only one server name, the objects are removed from the current domain controller. Specifies removing server metadata on <ServerName2>, the Domain Name System (DNS) name of the domain controller to which you want to connect. If you have identified replication partners in preparation for this procedure, specify a domain controller that is a replication partner of the removed domain controller.

on <ServerName2>

5. In Server Remove Configuration Dialog, review the information and warning, and then click Yes to remove the server object and metadata. At this point, Ntdsutil confirms that the domain controller was removed successfully. If you receive an error message that indicates that the object cannot be found, the domain controller might have been removed earlier. 6. At the metadata
cleanup:

and ntdsutil: prompts, type quit, and then press ENTER.

7. To confirm removal of the domain controller: Open Active Directory Users and Computers. In the domain of the removed domain controller, click Domain Controllers. In the details pane, an object for the domain controller that you removed should not appear. Open Active Directory Sites and Services. Navigate to the Servers container and confirm that the server object for the domain controller that you removed does not contain an NTDS Settings object. If no child objects appear below the server object, you can delete the server object. If a child object appears, do not delete the server object because another 475

application is using the object.

See Also
Delete a Server Object from a Site

Administering Active Directory Domain Rename
This guide provides information about planning and performing a domain rename operation in Windows Server 2008. For checklists of the various tasks to be performed during the different phases of this operation, see Appendix C: Checklists for the Domain Rename Operation. Suggested formats for a variety of worksheets that you can use for gathering information about your Active Directory Domain Services (AD DS) infrastructure are included in Appendix D: Worksheets for the Domain Rename Operation. You can use these worksheets for planning and tracking progress as you proceed with your domain rename operation.

In this guide
• • • Introduction to Administering Active Directory Domain Rename Managing Active Directory Domain Rename Additional Resources for the Domain Rename Operation

Introduction to Administering Active Directory Domain Rename
You can use the Windows Server 2008 domain rename process to change the names of your Active Directory domains, and you can also use it to change the structure of the domain trees in your Active Directory forest. This process involves updating the Domain Name System (DNS) and trust infrastructures as well as Group Policy and Service Principal Names (SPNs). The ability to rename domains gives you the flexibility to make important name changes and forest structural changes as the needs of your organization change. Using domain rename, you can change the name of a domain, but you can also change the structure of the domain hierarchy. You can also change the parent of a domain or move a domain in one domain tree to another domain tree. The domain rename process can accommodate scenarios involving acquisitions, mergers, or name changes in your organization, but it is not designed to accommodate forest mergers or the movement of domains between forests.

476

Important It is extremely important and highly recommended that you test the domain rename operation before you perform it in a production environment. First, perform the domain rename operation that is described in this section in a test environment that has a minimum of two domains. Familiarizing yourself with the specifics of each stage in the domain rename operation in a test environment will provide you with not only a much better understanding of the operation itself but also better prepare you to troubleshoot any issues that may arise during the domain rename operation in a production forest. For more information, see Domain Rename Technical Reference (http://go.microsoft.com/fwlink/? LinkID=122922).

Domain rename requirements
The following conditions must be in effect before you can begin a domain rename operation: • Forest functionality: You can rename domains only in a forest where all of the domain controllers are running Windows Server 2008 or Windows Server 2003 Standard Edition, Windows Server 2008 or Windows Server 2003 Enterprise Edition, or Windows Server 2008 or Windows Server 2003 Datacenter Edition operating systems, and the Active Directory forest functional level has been raised to either Windows Server 2003 or Windows Server 2008. The domain rename operation will not be successful if the forest functional level is set to Windows 2000 native. For more information about forest functional levels and for procedures to determine and set forest functional levels, see Enabling Windows Server 2008 Advanced Features for Active Directory Domain Services (http://go.microsoft.com/fwlink/?LinkID=105303). • Administrative credentials: You must have Enterprise Admins credentials to perform the various procedures for the domain rename operation. If you are running Microsoft Exchange, the account that you use must also have Full Exchange Administrator credentials. • Control Station: The computer that you use as the control station for the domain rename operation must be a member computer (not a domain controller) running Windows Server 2008 Standard Edition, Windows Server 2008 Enterprise Edition, or Windows Server 2008 Datacenter Edition. • Distributed File System (DFS) root servers: So that you can rename a domain with domainbased DFS Namespace (DFSN) roots, all DFSN root servers must be running Windows 2000 with Service Pack 3 (SP3), Windows Server 2003, or Windows Server 2008 operating systems. • If your forest contains Exchange 2003 Service Pack 1 (SP1) servers, you can run the Windows Server 2008 domain rename operation, but you must also use the Exchange Domain Rename Fix-up Tool to update Exchange attributes. For more information, see Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup) (http://go.microsoft.com/fwlink/? LinkID=122982). The document that accompanies this tool describes when and how to perform Exchange-related tasks. To perform a domain rename operation, Exchange must not be installed on any domain controllers. If a domain controller is running Exchange, move the Exchange data off the domain controller and then uninstall Exchange.

477

Important The Windows Server 2008 domain rename operation is not supported in an Active Directory forest that contains Exchange Server 2003, Exchange Server 2003 SP2, Exchange Server 2007, or Exchange Server 2007 SP1. Note You can use "Checklist: Satisfying Domain Rename Requirements" in Appendix C: Checklists for the Domain Rename Operation to make sure that you have met all the necessary requirements for the domain rename operation.

Managing Active Directory Domain Rename
This section includes the following tasks for managing Windows Server 2008 Active Directory domain rename: • • • Preparing for the Domain Rename Operation Performing the Domain Rename Operation Completing the Domain Rename Operation

Preparing for the Domain Rename Operation
This task helps you prepare for the domain rename operation. The goal of the preparation phase for the domain rename operation is to ensure that the prerequisites for the domain rename operation are in place. Completing these preliminary tasks will ensure a smooth implementation of domain renaming or domain restructuring in your forest. You can use the "Checklist: Preparing for the domain rename operation" in Appendix C: Checklists for the Domain Rename Operation to make sure that you have completed all of the required preliminary tasks. If these prerequisites are not satisfied, domain rename cannot be performed successfully. To complete this task, perform the following procedures: • • • • • • • • Adjust Forest Functional Level Create Necessary Shortcut Trust Relationships Prepare DNS Zones Redirect Special Folders to a Standalone DFSN Relocate Roaming User Profiles to a Standalone DFSN Configure Member Computers for Host Name Changes Prepare Certification Authorities Exchange-Specific Steps: Prepare a Domain that Contains Exchange

478

Adjust Forest Functional Level
You can use this procedure to adjust the forest functional level for a domain rename operation. The domain rename operation is supported within an Active Directory forest if, and only if, all domain controllers in the forest are running Windows Server 2003 or Windows Server 2008 Standard Edition, Windows Server 2003 or Windows Server 2008 Enterprise Edition, or Windows Server 2003 or Windows Server 2008 Datacenter Edition, and the forest functionality has been raised to Windows Server 2003 or Windows Server 2008. Therefore, before you can rename a domain in your Active Directory forest, you must ensure that the forest functionality has been set to at least Windows Server 2003 or raised to Windows Server 2008.

Setting forest functional level to Windows Server 2003 or Windows Server 2008
You can set the forest functional level to Windows Server 2003 if all domain controllers in the forest run either Windows Server 2003 or Windows Server 2008 operating systems. If any domain controller in the forest is still running Windows 2000, you cannot set the forest functional level to Windows Server 2003. You can set the forest functional level to Windows Server 2008 if all domain controllers in the forest run Windows Server 2008 operating system. If any domain controller in the forest is still running Windows Server 2003, you cannot set the forest functional level to Windows Server 2008. For more information, see Understanding AD DS Functional Levels (http://go.microsoft.com/fwlink/? LinkId=124107). To set the forest functional level to Windows Server 2003 or Windows Server 2008 1. Open the Active Directory Domains and Trusts snap-in: click Start, click Administrative Tools, and then click Active Directory Domains and Trusts. 2. In the console tree, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level. 3. In Select an available forest functional level, do one of the following: • To raise the forest functional level to Windows Server 2003, click Windows Server 2003, and then click Raise. • To raise the forest functional level to Windows Server 2008, click Windows Server 2008, and then click Raise. Caution Do not raise the forest functional level to Windows Server 2008 if you have, or will have, any domain controllers that are running Windows Server 2003 or earlier. After you raise the forest functional level to Windows Server 2008, you cannot change the level back to Windows Server 2003.

479

Create Necessary Shortcut Trust Relationships
You can use this procedure to create the necessary shortcut trust relationships for a domain rename operation. You can reposition any domain within the domain tree hierarchy of a forest, with the exception of the forest-root domain. In other words, although the forest root domain can be renamed (its Domain Name System (DNS) and NetBIOS names can change), it cannot be repositioned in such a way that you designate a different domain to become the new forest root domain. If your domain rename operation involves restructuring the forest by repositioning the domains in the domain tree hierarchy, as opposed to simply changing the names of the domains inplace, first create the necessary shortcut trust relationships between domains so that the new forest structure has two-way, transitive trust paths between every pair of domains in the target forest, just as your current forest does.

Types of trust relationships
A hierarchy of Active Directory domains is implemented by trust relationships between domains. The following types of trust relationships are established between domains within an Active Directory forest: • Parent-child: The trust that is established when you create a new domain in an existing tree in the forest. The Active Directory Domain Services (AD DS) installation process creates a transitive, two-way trust relationship automatically between the new domain (the child domain) and the domain that immediately precedes it in the namespace hierarchy (the parent domain). • Tree-root: The trust that is established when you add a new domain tree to the forest. The installation process for AD DS creates a transitive, two-way trust relationship automatically between the domain that you are creating (the new tree-root domain) and the forest root domain. • Shortcut: A manually created, one-way, transitive trust relationship between any two domains in the forest, created to shorten the trust path. To establish two-way, shortcut trust relationships between two domains, you set up a shortcut trust relationship manually in each direction. The effect of the transitive, two-way trust relationships that are created automatically by the installation process for AD DS is that there is complete trust between all domains in an Active Directory forest—every domain has a transitive trust relationship with its parent domain, and every tree-root domain has a transitive trust relationship with the forest root domain. If you use the domain rename operation to restructure an existing Active Directory forest by altering the domain tree hierarchy, automatic creation of the necessary trust relationships does not occur. For this reason, as part of the preparation phase of domain rename, the trust relationships that are required to preserve complete trust between all domains in your new forest (after restructuring) must be precreated manually.

480

Precreating parent-child trust relationships for a restructured forest
If you plan to use the domain rename operation to reposition one or more domains in the domain tree hierarchy, for each domain that you plan to reposition, the necessary shortcut trust relationships must be created between the domain that you want to reposition and its new parent domain (or the forest root domain, if the repositioned domain becomes a tree root). These precreated trust relationships substitute for the required tree-root or parent-child trust relationships that will be missing in the restructured forest.

Precreating a parent-child trust relationship
For example, suppose that you want to restructure the cohowinery.com forest, shown in the following illustration, so that the products.sales.cohowinery.com domain becomes a child of the cohowinery.com domain. Before you perform the domain rename operation to carry out this restructure, you must first create a two-way, transitive shortcut trust relationship between products.sales.cohowinery.com and cohowinery.com. This trust relationship precreates the twoway, parent-child trust relationship that will be required for the targeted parent and child domains. The following illustration shows the “before” and “after” domain structures and the shortcut trust relationships you have to create that will serve as parent-child trust relationships in the target forest.

Pre-creating multiple parent-child trust relationships
For scenarios in which you have to restructure a domain that is both a child domain and a parent domain, you might have to create shortcut trust relationships in two places. For example, suppose that you want to restructure the cohowinery.com forest, shown in the following illustration, to move 481

the hr.sales.cohowinery.com domain so that it becomes a child of the eu.cohowinery.com domain. At the same time, you want to make its child domain, payroll.hr.sales.cohowinery.com, become a direct child of its current parent domain, sales.cohowinery.com. To perform this restructure operation, you first have to create two shortcut trust relationships that will become the parent-child trust relationships for the new forest that follows the restructuring, as shown: • A two-way, transitive shortcut trust relationship between the eu.cohowinery.com and hr.sales.cohowinery.com domains, which will create a two-way, transitive parent-child trust relationship between eu.cohowinery.com and hr.eu.cohowinery.com after restructuring • A two-way, transitive shortcut trust relationship between the sales.cohowinery.com and payroll.hr.sales.cohowinery.com domains, which will create a two-way, transitive parent-child trust relationship between sales.cohowinery.com and payroll.sales.cohowinery.com after restructuring

482

These shortcut trusts are responsible for maintaining the two-way, transitive trust relationships that are required between the newly renamed domains when the domain rename operation is complete.

Precreating a tree-root trust relationship with the forest root domain
When a domain is renamed to become a new tree root, the new tree-root domain must have a twoway, transitive trust relationship with the forest root domain. For this scenario, you create a two-way shortcut trust relationship between the domain that you want to rename to become a new tree-root domain and the forest root domain. For example, suppose that you have a deep tree and you want to create a new tree by moving the lowest-level domain to become a tree-root domain. The following illustration shows the two-way shortcut trust relationship that you create, and the tree-root trust relationship it provides after the restructure, when you rename the eu.sales.cohowinery.com domain to create the tree-root domain cohoeurope.com.

Creating shortcut trust relationships
Analyze the target forest structure that you intend to achieve. Consider the requirement of a twoway, transitive trust relationship between each pair of domains in the forest, and create a list of shortcut trust relationships that are necessary to preserve full trust relationships between all the domains in the target forest. Create the shortcut trust relationships so that they are in place when you begin the domain rename procedure. You can use "Worksheet 2: Trust Information" in 483

Appendix D: Worksheets for the Domain Rename Operation to document all trust relationships that are necessary to preserve full trust relationships between all the domains in the target forest. For information about how to create shortcut trust relationships, see Create a Shortcut Trust (http://go.microsoft.com/fwlink/?LinkId=124112).

Prepare DNS Zones
You can use this procedure to prepare Domain Name System (DNS) zones for Active Directory domain rename. When an application or client requests access to Active Directory Domain Services (AD DS), an Active Directory domain controller is located by the domain locator (DC Locator) mechanism. In response to client requests for AD DS services, DC Locator uses service (SRV) resource records in Domain Name System (DNS) to locate domain controllers. In the absence of these DNS service location (SRV) resource records, directory clients experience failures when they attempt to access AD DS. For this reason, before you rename an Active Directory domain, you have to be sure that the appropriate DNS zones exist for the forest and for each domain. If the appropriate zones do not exist in DNS, you have to create the DNS zone or zones that will contain the service (SRV) resource records for the renamed domains. We also strongly recommend that you configure the zone(s) to allow secure dynamic updates. This DNS zone requirement applies to each domain that is renamed as part of the domain rename operation. The DNS requirements to rename an Active Directory domain are identical to the DNS requirements to support an existing Active Directory domain. Your current DNS infrastructure already provides necessary support for your Active Directory domain by using its current name. Usually, you only have to mirror the existing DNS infrastructure to add support for the planned new name of your domain. For example, suppose that you want to rename an existing Active Directory domain sales.cohovineyard.com to marketing.cohovineyard.com. If the service (SRV) resource records that are registered by the domain controllers of the sales.cohovineyard.com Active Directory domain are registered in the DNS zone named sales.cohovineyard.com, you have to create a new DNS zone called marketing.cohovineyard.com which corresponds to the new name of the domain. For more information about how to configure DNS to provide support for AD DS, see Creating a DNS Infrastructure Design (http://go.microsoft.com/fwlink/?LinkId=124108). Before you begin the domain rename process, verify that any new zones that are required have been created and configured to allow dynamic updates. Analyze your current DNS infrastructure in relation to the new forest structure that you want after the domain rename operation has completed and compile a list of DNS zones that have to be created. You can use "Worksheet 3: DNS Zone Information" in Appendix D: Worksheets for the Domain Rename Operation to document this list. For more information about how to create DNS zones, see Add a Forward Lookup Zone (http://go.microsoft.com/fwlink/?LinkID=108851). For more information about how to configure dynamic updates, see Allow Dynamic Updates (http://go.microsoft.com/fwlink/?LinkId=124109).

484

Redirect Special Folders to a Standalone DFSN
You can use this procedure to redirect special folders to the standalone Distributed File System Namespaces (DFSN) for domain rename. Windows Server 2003 and Windows Server 2008 help redirect a set of special folders for users, such as the My Documents folder, from the local computer to a network location. Folder Redirection is an extension to Group Policy that you can use to identify network locations for these folders on specific servers or DFSN. If you redirect folders to a network location that uses domain-based DFSN (Domain_Name\DFSN_Name), renaming the Active Directory domain invalidates the path to the domain-based DFSN. If the redirected path is no longer valid, Folder Redirection stops working. Note If the NetBIOS name of a domain is used in a domain-based DFSN and the NetBIOS name of the domain is not changed during the domain rename operation, the path to this domainbased DFSN will continue to be valid. So that Folder Redirection can continue to work after a domain rename operation, folders that are redirected to a domain-based DFSN for a domain that is going to be renamed must instead be redirected to a standalone DFSN (also known as server-based DFSN) before you rename the domain. Stand-alone DFSNs are not affected by the domain rename operation. You can configure Folder Redirection to a stand-alone DFSN instead of a domain-based DFSN by using the Folder Redirection Group Policy extension. For information about how to use Group Policy to redirect special folders to a network location, see Use Folder Redirection (http://go.microsoft.com/fwlink/?LinkId=124089).

Relocate Roaming User Profiles to a Standalone DFSN
You can use this procedure to relocate roaming user profiles to a stand-alone Distributed File System Namespace (DFSN) for domain rename. Windows Server 2003 Server and Windows Server 2008 provide support for roaming user profiles where the user profile (as well as the home directory) can be located on a network location. Just as for Folder Redirection, if roaming user profiles (and the home directory) are placed on a network location by using a domain-based DFSN, renaming the domain invalidates the path to this DFSN and roaming profiles that use this path stop working. Note If the NetBIOS name of a domain is used in a domain-based DFSN and the NetBIOS name of the domain is not changed during a domain rename operation, the path to the domainbased DFSN continues to be valid.

485

To ensure that network share-based user profiles continue to work after a domain rename operation, user profiles that are located on a domain-based DFSN for a domain that is going to be renamed must be relocated to a stand-alone DFSN (also known as a server-based DFSN). Serverbased DFSNs are not affected by the domain rename operation. For information about how to create roaming user profiles, see Configuring Roaming User Profiles (http://go.microsoft.com/fwlink/?LinkID=122940).

Configure Member Computers for Host Name Changes
You can use this procedure to configure member computers for host name changes in a domain rename operation. By default, the primary Domain Name System (DNS) suffix of a member computer of an Active Directory domain is configured to change automatically when domain membership of the computer changes. The same default behavior is true when the DNS name of the domain to which a computer is joined changes. For this reason, rename of an Active Directory domain can cause modification of the primary DNS suffix and, therefore, of the full DNS host names of the computers that are the members of the renamed domain. For example, if the sales.cohowinery.com domain is renamed to marketing.cohowinery.com, the primary DNS suffix of the member computers of this domain might also change from sales.cohowinery.com to marketing.cohowinery.com, depending on whether the default behavior is in effect. If the default behavior is in effect, the full DNS host name of a computer in the renamed domain changes from host.sales.cohowinery.com to host.marketing.cohowinery.com.

Conditions for automatic computer name change
The primary DNS suffix, and therefore the full DNS name of a member computer in an Active Directory domain, changes automatically when the domain is renamed if both of the following conditions are true: • The primary DNS suffix of the computer is configured to be updated when domain membership changes. • No Group Policy that specifies a primary DNS suffix is applied to the member computer. These conditions represent the default configuration for computers that are running Windows Server 2003 and Windows Server 2008. Remember that the DNS suffix setting also applies to servers that are running Microsoft Exchange. When you determine the primary DNS suffix configuration for your servers, also check your Exchange servers. Note The DNS host names of domain controllers in a renamed domain are not changed automatically to use the new domain DNS name as the primary DNS suffix, regardless of the primary DNS suffix configuration. In other words, the DNS names of domain controllers 486

in a renamed domain will remain unchanged. You can rename the domain controllers in a separate step after the domain rename operation is complete by using a special domain controller rename procedure. For more information about how to rename a domain controller, see Renaming a Domain Controller.

Replication effects of renaming large numbers of computers
If the conditions that prompt automatic update of the DNS host names for all computers in the domain are true and if there are a large number of member computers in the domain that is being renamed, replication of that many changes might cause excessive traffic on your network. Recall that a computer name change triggers update of the dnsHostName and servicePrincipalName attributes on the corresponding computer account in Active Directory Domain Services (AD DS). These attributes will typically be updated when the member computer is restarted, as required by the domain rename operation after you rename the domain. Update of these attributes by a large number of computers within a short period of time might trigger replication activity that saturates the network. Moreover, computer name change triggers update of the host (A), host (AAAA), and pointer (PTR) resource records in the DNS database. Such updates also cause additional replication traffic, regardless of whether DNS zones are stored in AD DS or in some other DNS store. For these reasons, you should prepare for the domain rename operation in advance by reconfiguring the default behavior that changes the primary DNS suffix on member computers when a domain is renamed. Important If you do not think that the resulting replication traffic poses a risk of network congestion or saturation to your infrastructure, you can allow for the DNS names of the member computers in the renamed domain to change automatically as a result of the domain rename operation. In other words, if there is no risk of network congestion, skip this preparatory step of configuring member computers for host name changes and proceed with the next step: Prepare Certification Authorities. On the other hand, if the number of member computers in the domain to be renamed is large and the consequent replication traffic poses the risk of network congestion in your environment, you should prepare for an Active Directory domain rename operation in advance so that you can rename the member computers in smaller batches to mitigate the replication traffic problem. In this case, you can take steps so that computers will not be renamed after domain rename by ensuring that at least one of the two conditions in Conditions for Automatic Computer Name Change is not true. Note You do not have to match the DNS suffix to the new domain name. If your current implementation uses a primary DNS suffix that does not match the DNS name of the domain to which the member computers are joined and if you do not want the DNS suffix to change following domain rename, you can ensure that these computers are not renamed

487

after the domain rename by verifying that at least one of the two conditions in Conditions for Automatic Computer Name Change is not satisfied.

Using Group Policy to apply the new primary DNS suffix
To avoid a replication "storm" that can result from thousands of computer names being changed at approximately the same time, you can use Group Policy to revise the primary DNS suffix to the new domain name before the domain rename so that member names are not automatically updated but have the correct primary DNS suffix at the time that you perform the domain rename.

Apply the new primary DNS suffix before renaming domains
If you establish the planned new name of the domain as the primary DNS suffix for all computers in the domain before you rename the domain, you can ensure that your member computers are not renamed automatically after the domain rename opration. In this way, you can avoid a potential problem in which replication of name-change updates negatively affects network performance immediately after the domain rename. You can use the Group Policy setting Primary DNS Suffix to establish the primary DNS suffix for the domain as the new DNS domain name. When this Group Policy setting is in effect, it overrides the default behavior of changing the primary DNS suffix when the DNS name of the domain changes. In this case, the computer names remain the same when you rename the domain and replication of name changes does not occur.

Apply Group Policy in stages to avoid significant replication
When you apply the Group Policy setting, Primary DNS Suffix changes the DNS suffix and precipitates a name change. Therefore, you must manage the Group Policy application in stages, depending on how many member computers are in the domain that is being renamed. To apply Group Policy to all member computers in the domain or domains that are being renamed, while also avoiding replication on a large scale, you have to divide computer objects among several locations in AD DS—either organizational units (OUs) or sites, or both. In deployments in which member computers exist in numbers that can affect network efficiency if all computers were renamed at the same time, you want to have computers distributed among several OUs, for ease of administration. If member computers at both the site and OU levels are too numerous to undergo a name change without causing excessive replication, you might want to create additional organizational units to temporarily house some of the computers so that you can apply Group Policy in stages. Important Do not apply the Group Policy setting to cause a DNS host name change for member servers that are housing software distribution points for managed software deployment in your domain. You should wait until the step Fix Group Policy Objects and Links later in this

488

document. The member servers that house software distribution points will change their DNS host name at that step after they are restarted. You can rename member computers one group at a time by using the following sequence of tasks: 1. Estimate the largest number of computers (N) that can be renamed in your environment so that the resulting replication traffic can be sustained by your network without becoming saturated. It is our expectation that 1000 is an acceptable number. 2. Divide the member computers in the domain to be renamed into groups. Each group should contain no more than the number of computers N estimated in step 1, so that the new primary DNS suffix can be applied to one group at a time. Note The "groups" that are specified in this step are purely imaginary entities that represent some collection of computers. There might be no actual object that corresponds to such a group in the domain. For example, the combination of two OUs , or one site, or one site plus an OU, and so on, might be used to form one group, provided that the number of computers in the group does not exceed the number N of computers that is specified in step 1. If existing sites and OUs all contain more computers than the number N that is specified in step 1, you might have to create one or more temporary OUs to group computers so that the new primary DNS suffix can be applied to one group (in this case, one or more OUs ) at a time. As an alternative, you can restrict the scope of application of Group Policy to one group by creating a temporary security group that consists of the group of computers that should receive the policy and by setting security permissions on the Group Policy object (GPO) accordingly using the security group that you just created. 3. Create a staggered schedule that determines when the new primary DNS suffix will be applied to each group of computers that you established in step 2. Ensure that there is sufficient time between two consecutive applications of the Group Policy setting Primary DNS Suffix to two different groups of computers to allow replication to occur. Replication of the updated dnsHostName and servicePrincipalName attributes on computer accounts and replication of the DNS records of the renamed computers must be completed fully during the scheduled gap. 4. Configure the domain that is being renamed to allow member computers of the domain to register the new primary DNS suffix in the dnsHostName attribute of their corresponding computer accounts in AD DS.

Configuration required before the application of Group Policy
When you apply the Group Policy setting Primary DNS Suffix, the DNS suffix of member computers will no longer match the DNS name of the domain of which they are members. To allow the member computers of a domain to have a primary DNS suffix that does not match the DNS domain name, you must first configure the domain to accept the names that the DNS suffix can have. This configuration must be in place before you can set Group Policy to apply to a set of computers. 489

To configure the set of DNS suffixes that can be applied to computers in the domain, add a new value (or values) to the msDS-AllowedNDSSuffixes multivalued attribute of the domain object (the domainDns object for the domain) so that the attribute contains a list of DNS suffixes that member computers of the Active Directory domain can have. When you apply the Group Policy setting Primary DNS Suffix, you will specify one of the DNS suffixes that you have added to the msDSAllowedNDSSuffixes attribute. If you apply the Primary DNS suffix Group Policy setting to the computers in the domain to be renamed, we highly recommend that you set the DNS Suffix Search List Group Policy setting and apply it to the computers in the domain being renamed. The DNS Suffix Search List setting should contain the old primary DNS suffix, new primary DNS suffix, and potentially parent suffixes of the old and new primary DNS suffixes. (The latter depends on whether parent name spaces are being used in the organization.) For example, suppose that the old name of a domain was payroll.hr.sales.cohowinery.com (that also corresponds with the old primary DNS suffix). Also, suppose that the new name of the domain is payroll.sales.cohowinery.com (that also corresponds with the new primary DNS suffix). The DNS Suffix Search List should contain the following suffixes: • • • • • payroll.hr.sales.cohowinery.com payroll.sales.cohowinery.com hr.sales.cohowinery.com sales.cohowinery.com cohowinery.com

… and it may contain these suffixes:

Such configuration preserves the ability of users to resolve the DNS names of computers in the domain that is being renamed by specifying first label only of the full DNS names of computers— even during the transition period when a user’s computer and resource server may have different primary DNS suffixes. For the same reason, if computers in another domain were configured with DNS Suffix Search List that contains the old name of a domain being renamed, during the domain rename operation those computers should be reconfigured so that DNS Suffix Search List is updated to contain both the old and new domain names.

Configuring member computers for host name changes in large deployments
If your AD DS implementation is large enough to warrant updating the primary DNS suffix before the domain rename (that is, you want to avoid the effects of excessive replication of computer name changes that follow domain rename), you must complete the following tasks: • • Determine the Primary DNS Suffix Configuration Determine Whether Group Policy Controls the Primary DNS Suffix

• Configure the Domain to Allow a Primary DNS Suffix that Does Not Match the Domain Name 490



Apply Group Policy to Set the Primary DNS Suffix

Determine the primary DNS Suffix configuration
As a preliminary step, if you do not know how your member computers are configured in relation to updating the primary DNS suffix if the membership domain changes, you first want to establish these conditions. The following procedures describe two ways to view the setting for a member computer that determines whether the primary DNS suffix changes when the name of the membership domain changes. To check for primary DNS suffix update configuration using Control Panel 1. On a member computer, in Control Panel, double-click System. 2. Click the Change settings link. 3. On Computer Name tab, click Change. 4. Click More, and then verify whether Change primary domain suffix when domain membership changes is selected. 5. Click OK until all dialog boxes are closed.

To check for primary DNS suffix update configuration for a computer using the registry 1. On the Start menu, click Run. 2. In Open, type regedit, and then click OK. Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. 3. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. 4. Verify whether the value of REG_RWORDSyncDomainWithMembership is 0x1. This value indicates that the primary DNS suffix changes when the domain membership changes.

Determine whether Group Policy controls the primary DNS suffix
You can also determine whether Group Policy is applied to the computer to specify the primary DNS suffix. There are several ways to discover this information, as described in the following procedure. You can determine whether Group Policy specifies the primary DNS suffix for a computer on a member computer using either of the following two procedures.

491

To determine whether Group Policy specifies the primary DNS suffix by using the command line 1. To open a command prompt, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
gpresult

3. In the output, under Applied Group Policy objects, check to see whether Primary DNS Suffix is listed. Or 4. Type the following command, and then press ENTER:
ipconfig /all

5. Check Primary DNS Suffix in the output. If it does not match the primary DNS suffix that is specified in Control Panel for the computer, the Primary DNS Suffix Group Policy setting is applied.

To determine whether Group Policy specifies the primary DNS suffix by using the registry 1. On the Start menu, click Run. 2. In Open, type regedit and then click OK. 3. Navigate to HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\WindowsNT\DNSclient. 4. Check for the presence of the entry Primary DNS Suffix. If a value is present, the Primary DNS Suffix Group Policy setting is applied to the computer.

Configure the domain to allow a primary DNS suffix that does not match the domain name
Before you apply Group Policy to set the primary DNS suffix for each renamed domain, create a list of the DNS suffixes that you want to use for each domain. The only primary DNS suffix available to the domain, by default, is the DNS name of the domain itself. To make these different DNS suffixes available to member computers, you must first make the DNS suffixes known to the domains in which you want to use them. You add DNS suffixes to the domain by editing the attribute msDSAllowedDNSSuffixes on the domain object to contain the additional DNS domain names that are available to be used as DNS suffixes for that domain. For you to be able to add a primary DNS suffix that is different from the current DNS domain name, your environment must meet the following requirements: • All domain controllers in the domain must be running Windows Server 2003 or Windows Server 2008. • For each new DNS suffix that you add, a subdomain by that name must exist in DNS.

492

Caution The same value in the msDS-AllowedDNSSuffixes attribute cannot be used for more than one domain in the forest. This undesired configuration enables a malicious administrator of a computer that is joined to one such domain to set the servicePrincipalName attribute of its computer account to the same value as the Service Principal Name (SPN) of a computer in the other domain that is configured to allow the same DNS suffix. Such a configuration prevents Kerberos authentication against both of these computers. The attribute msDS-AllowedDNSSuffixes is an attribute of the domain object. Therefore, you must set DNS suffixes for each domain whose name is going to change. To use ADSI Edit to add DNS suffixes to msDSAllowedDNSSuffixes 1. Click Start menu, click Administrative Tools, and then click ADSI Edit. 2. Double-click the domain directory partition for the domain that you want to modify. 3. Right-click Domain container object, and then click Properties. 4. On the Attribute Editor tab, in Attributes, double-click the attribute msDSAllowedDNSSuffixes. 5. In the Multi-valued String Editor dialog box, in Value to add, type a DNS suffix, and then click Add. 6. When you have added all the DNS suffixes for the domain, click OK. 7. Click OK to close the Properties dialog box for that domain. 8. In the console tree, right-click ADSI Edit, and then click Connect to. 9. Under Computer, click Select or type a domain or server. 10. Type the name of the next domain for which you want to set the primary DNS suffix, and then click OK. 11. Repeat steps 2 through 7 for that domain. 12. Repeat steps 8 through 10 to select each subsequent domain and repeat steps 2 through 7 to set the primary DNS suffix for each subsequent domain that is being renamed.

Apply Group Policy to set the primary DNS suffix
Start applying the Group Policy setting Primary DNS Suffix to one group of computers at a time. (For more information, see Apply Group Policy in stages to avoid significant replication.) The new primary DNS suffix must be applied to all member computers in a domain before the domain is renamed. Note The group of member computers to which this Group Policy setting is applied will have to be restarted for the host name change to take effect. To apply the Group Policy setting Primary DNS Suffix to groups of member computers 1. Open the Group Policy Management Editor snap-in: click Start, click Administrative 493

Tools, and then click Group Policy Management. 2. In Group Policy Management Editor, right-click the domain or OU that contains the group of computers to which you are applying Group Policy. 3. In Group Policy Objects, right-click the GPO that you want to contain the Primary DNS Suffix setting, and then click Edit. Note To create a new GPO that will contain the Primary DNS Suffix setting, right-click Group Policy Objects, click New, and then type a name for the object. 4. Under Computer Configuration, expand Policies and Administrative Templates, Network, and then click DNS Client. 5. In the results pane, double-click Primary DNS Suffix. 6. Click Enabled, and then in the Enter a primary DNS suffix box, type the DNS suffix for the domain whose member computers are in the group that you selected in step 2. After the Active Directory domain has been renamed and all member computers have had time to restart, you can disable the Group Policy setting that you enabled in step 6 of the previous procedure. Note The steps in the previous procedure result in naming member computers only, not domain controllers. Renaming mission-critical servers, such as domain controllers, requires special preparation that is beyond the scope of this document. For information about how to rename a domain controller, see Renaming a Domain Controller. We strongly recommend that you carefully read this Help documentation and then rename domain controllers in a renamed domain according to the specified recommendations only after the domain rename operation has completed successfully.

Prepare Certification Authorities
You can use this procedure to prepare certification authorities (CAs) for domain rename. Management of enterprise certificates can be sustained through a domain rename operation when the following requirements are in effect before domain rename: • The CAs are not installed on domain controllers. • As a best practice, all the CAs should include both Lightweight Directory Access Protocol (LDAP) and Hypertext Transfer Protocol (HTTP) URLs in their Authority Information Access (AIA) and Certificate Distribution Point (CDP) extensions. Caution If any certificate that the CA issues has only one of these URL types, the certificate may or may not work. Depending on the complexity of your domain configuration, steps in this document might not be sufficient for proper management of CAs after the domain rename 494

operation. Proceed with these steps only if you have considerable expertise in handling Microsoft CAs. If one or more of the following conditions exist at the time of domain rename, CA management is not supported: • The CA is configured to have only LDAP URLs for its CDP or AIA. Because the old LDAP extensions would be invalid after the domain rename operation, all the certificates that are issued by the CA are no longer valid. As a workaround, you have to renew the existing CA hierarchy and all issued End Entity certificates. • After the domain rename operation, the name constraints might not be valid. As a workaround, you will have to reissue cross-certificates with appropriate name constraints. • A Request for Comments (RFC) 822–style e-mail name is used in the user account. If the CA (or the certificate template) is configured to include RFC 822-style e-mail names and this name style is used in the certificates that are issued, these certificates will contain an incorrect e-mail name after domain rename operation. Any such Active Directory accounts should be changed before any certificate is issued. As a best practice, the default LDAP and HTTP URLs require no special configuration before the domain rename operation. Before you begin the domain rename operation, ensure that the certificate revocation lists (CRLs) and the CA certificates will not expire soon. If you find that they are close to expiration, complete the following tasks before the domain rename operation: 1. Renew the CA certificates. 2. Issue a new CRL with the appropriate validity period. 3. Wait until both of these previous items have propagated to all client computers. For more information, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/? LinkID=122981).

Exchange-Specific Steps: Prepare a Domain that Contains Exchange
Important You can use this procedure to prepare a domain that contains Exchange for a domain rename operation. The Windows Server 2008 domain rename operation is not supported in an Active Directory forest that contains Exchange Server 2003, Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, or Exchange Server 2007 Service Pack 1 (SP1). If your forest contains Exchange 2003 Service Pack 1 (SP1) servers, you can run the Windows Server 2008 domain rename operation, but you must also use the Exchange Domain Rename Fix-up Tool to update Exchange attributes. For more information, see Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup) http://go.microsoft.com/fwlink/? LinkID=122982). This document describes preliminary steps and instructions for running the 495

Exchange Domain Rename Fix-up Tool. As part of the preliminary steps, you must move Exchange off all domain controllers and discontinue Exchange configuration changes.

Performing the Domain Rename Operation
This task provides information about performing the domain rename operation. This task describes in detail the procedures that you complete to perform the domain rename operation in your forest. Be sure that you have reviewed and completed every preliminary procedure that applies to your domain rename conditions, as described in Preparing for the Domain Rename Operation. After you complete all the procedures in this task, the target domain name changes will be effective in your forest. The domain name changes will have propagated toall the domain controllers in your forest, as well as to the member computers in the renamed domains. A brief period of interruption in your Active Directory forest service occurs during the time when all of the domain controllers in the forest are automatically restarting. The exact point at which the service interruption occurs is indicated in Run Domain Rename Instructions. Except for this brief period of interruption, the Active Directory Domain Services (AD DS) service should continue to be available and function normally throughout the rest of the domain rename process.

Task requirements The following is required to perform the procedures for this task: • • • • • • • • • • • • Rendom.exe Repadmin.exe Gpfixup.exe Set Up the Control Station Freeze the Forest Configuration Back Up All Domain Controllers Generate the Current Forest Description Specify the New Forest Description Generate Domain Rename Instructions Push Domain Rename Instructions to All Domain Controllers and Verify DNS Readiness Verify Readiness of Domain Controllers Run Domain Rename Instructions

To complete this task, perform the following procedures:

• Exchange-Specific Steps: Update the Exchange Configuration and Restart Exchange Servers • • Unfreeze the Forest Configuration Re-establish External Trusts 496



Fix Group Policy Objects and Links

Set Up the Control Station
You can use this procedure to set up the control station for a domain rename operation. To perform an Active Directory domain rename operation, you must set up a single computer as the administrative control station for the entire domain rename operation. All the domain rename procedures are performed and controlled from this computer. You copy all the required tools to perform the domain rename operation to a directory on the local disk of the control station and run the tools from that control station. Although the domain rename operation involves contacting each domain controller in the forest, the domain controllers are contacted remotely by the domain rename tools from the control station. Prerequisites • Computer: Use a computer that is a member of a domain in the forest in which domain rename operation is to be performed to serve as the control station. • Operating system: The computer must be a member computer (not a domain controller) that is running Windows Server 2003 Standard Edition or Windows Server 2008 Standard, Windows Server 2003 Enterprise Edition or Windows Server 2008 Enterprise, or Windows Server 2003 Datacenter Edition or Windows Server 2008 Datacenter. Important Do not use a domain controller to act as the control station for the domain rename operation. • Operating system CD: You must have the Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition operating system CD. Membership in the Local Administrators group (or a write access to a local disk drive) on the computer that is the control station is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To set up the control station on a Windows Server 2003 member server 1. On a local disk drive of the selected control station computer, create a working directory for the domain rename tools, for example, C:\domren Note Each time that you use the tools in this procedure, run them from this directory. 2. Insert the Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition operating system CD into the CDROM drive and copy the files from the valueadd directory into your working directory as follows:
copy D:\valueadd\msft\mgmt\domren\*.* C:\domren

497

In particular, verify that the two tools Rendom.exe and Gpfixup.exe have been copied into the working directory on the control station. 3. Install the Support Tools from the Support\Tools folder on the Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition operating system CD. (To install Support Tools, run Suptools.msi in the Support\Tools directory.) In particular, verify that the tools Rendom.exe, Repadmin.exe, Dfsutil.exe, and Gpfixup.exe are installed on the control station. To set up the control station on a Windows Server 2008 member server 1. On a local disk drive of the selected control station computer, create a working directory for the domain rename tools, for example, C:\domren. Note Each time that you use the tools in this procedure, run them from this directory. 2. To obtain the necessary tools for the domain rename operation, install the Remote Server Administration Tools Pack. For more information, see Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/?LinkId=124111). Verify that the tools Rendom.exe, Repadmin.exe, Dfsutil.exe, and Gpfixup.exe are installed on the control station in the %\Windows\System32 directory. 3. Copy Rendom.exe, Repadmin.exe, Dfsutil.exe, and Gpfixup.exe tools from the %\Windows\System32 directory into your working directory as follows:
robocopy %:\Windows\System32 C:\domren rendom.exe repadmin.exe dfsutil.exe gpfixup.exe

Freeze the Forest Configuration
You can use this procedure to freeze the forest configuration for a domain rename operation. When your domain rename plan is in place and all preliminary procedures are complete, you must ensure that the configuration of your forest will not change until after the domain rename operation is complete. Therefore, before you begin the domain rename operation you must discontinue the following activities in your forest: • Creating new domains in, or removing existing domains from, your forest • Creating new application directory partitions in, or removing existing application directory partitions from, your forest • • Adding domain controllers to, or removing domain controllers from, your forest Creating or deleting shortcut trusts within your forest

• Adding attributes to, or removing attributes from, the set of attributes that replicate to the global catalog (the partial attribute set). 498

You can resume these activities after you successfully complete the domain rename operation. For more information see, Unfreeze the Forest Configuration.

Back Up All Domain Controllers
Back up all domain controllers before you begin a domain rename operation. Perform a full system state backup of all domain controllers in the forest. For more background information and detailed step-by-step instructions for backing up domain controllers, see the Step-by-Step Guide for Windows Server 2008 Active Directory Domain Services Backup and Recovery (http://go.microsoft.com/fwlink/?LinkId=93077).

Generate the Current Forest Description
You can use this procedure to generate a current forest description for a domain rename operation. In this procedure, you use the domain rename tool Rendom.exe to generate a textual description of your current forest structure as an XML-encoded file named Domainlist.xml, which contains a list of all domain directory partitions as well as application directory partitions that constitute your forest. This file includes an entry for every domain and application directory partition, and each entry is bounded by the <Domain></Domain> XML tags. Each entry for a domain (or an application directory partition) contains its naming data, which includes the object globally unique identifier (GUID) of the partition root object, the Domain Name System (DNS) name of the domain (or application directory partition), and the NetBIOS name of the domain. (An application directory partition does not have a NetBIOS name.) The domain name changes will be specified from this XML-encoded forest description file in the subsequent step of the domain rename operation. The following is a sample Domainlist.xml file that is generated in a forest with two domains named cohovineyard.com (with a NetBIOS name of COHOVINEYARD) and sales.cohovineyard.com (with a NetBIOS name of SALES). In addition to the two entries that correspond to the two domains in the forest, the following three entries appear. These entries correspond to the application directory partitions that the Active Directory–integrated DNS service uses: • • • DomainDnsZones.sales.cohovineyard.com DomainDnsZones.cohovineyard.com ForestDnsZones.cohovineyard.com

These application directory partitions must also be renamed.
<?xml version = “1.0”?> <Forest> <Domain> <!-- PartitionType:Application --> <Guid>59add6bb-d0e8-499e-82b9-8aaca5d3e18b</Guid> <DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname>

499

<NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <Guid>89cf8ae3-f4a3-453b-ac5c-cb05a76bfa40</Guid> <DNSname>sales.cohovineyard.com</DNSname> <NetBiosName>SALES</NetBiosName> <DcName></DcName> </Domain> <Domain> <!-- PartitionType:Application --> <Guid>f018941b-c899-4601-bfa7-5c017e9d31e7</Guid> <DNSname>ForestDnsZones.cohovineyard.com</DNSname> <NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <!-- PartitionType:Application --> <Guid>f018941b-c899-4601-bfa7-5c017e9d31f3</Guid> <DNSname>DomainDnsZones.cohovineyard.com</DNSname> <NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <! — - ForestRoot --> <Guid>89cf6b34-d753-32a8-da6b-6a8e04bc48a4</Guid> <DNSname>cohovineyard.com</DNSname> <NetBiosName>COHOVINEYARD</NetBiosName> <DcName></DcName> </Domain> </Forest>

Important The functional level of the forest in which you perform the domain rename operation must be set to Windows Server 2003 or Windows Server 2008. Otherwise, the domain rename tool, Rendom.exe, reports an error and it cannot proceed with further steps. 500

Membership in the Enterprise Admins group in the current forest and the Local Administrators group (or write access to the domain rename C:\domren working directory) on the control station computer is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Note You can use credentials other than those credentials with which you are currently logged on. To use alternative credentials, use the /user and /pwd command-line switches of rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool. To generate the current forest description file 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command to change to the working directory, and then press ENTER:
C:\domren

3. To generate the XML-encoded forest description file, at the command prompt, type the following command, and then press ENTER:
rendom /list

4. Save a copy of the current forest description file (Domainlist.xml) that was generated in step 3 as Domainlist-save.xml for future reference by using the following copy command:
copy domainlist.xml domainlist-save.xml

Note The Rendom tool contacts the domain controller that is the current domain naming operations master role owner in the target forest to gather the information that is necessary to generate the forest description file. The command might fail if the domain naming master is unavailable or unreachable from the control station.

Specify the New Forest Description
You can use this procedure to specify the new forest description for a domain rename operation. In this procedure, you use a text editor to specify your new target forest structure by editing the forest description file Domainlist.xml that you created with the procedure Generate the Current Forest Description. The new forest description, which is specified through changes to the domain and the application directory partition names in the Domainlist.xml file will form the starting point for the remainder of the steps in the domain rename operation. You can change either the Domain Name System (DNS) name (the field that is bounded by the <DNSname></DNSname> tags) or the NetBIOS name (the field that is bounded by the <NetBiosName></ NetBiosName> tags), or both names, for any given domain in the forest. You cannot, however, change the globally unique identifier (GUID) in the field that is bounded by the <Guid></ Guid> tags. 501

Furthermore, pay special attention to the fact that when the DNS name of a parent domain changes, the DNS name of its child domain should also be changed, unless you are deliberately restructuring the child domain into a new domain tree root in the forest. For example, if the root domain cohovineyard.com is renamed to cohowinery.com, the child domain sales.cohovineyard.com should also be renamed to sales.cohowinery.com, unless you want to make the domain sales.cohovineyard.com become the root of a new domain tree. Here is a sample of a forest description Domainlist.xml file before and after you edit it for domain name changes to rename the root domain from cohovineyard.com to cohowinery.com. This name change of the forest root domain also results in a renaming of the child domain from sales.cohovineyard.com to sales.cohowinery.com. Furthermore, assume that the NetBIOS name of the root domain is also being changed from COHOVINEYARD to COHOWINERY. BEFORE editing (root domain name: cohovineyard.com)
<Forest> <Domain> <!-— PartitionType:Application --> <Guid>59add6bb-d0e8-499e-82b9-8aaca5d3e18b</Guid> <DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname> <NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <Guid>89cf8ae3-f4a3-453b-ac5c-cb05a76bfa40</Guid> <DNSname>sales.cohovineyard.com</DNSname> <NetBiosName>SALES</NetBiosName> <DcName></DcName> </Domain> <Domain> <! — - PartitionType:Application --> <Guid> f018941b-c899-4601-bfa7-5c017e9d31e7</Guid> <DNSname>ForestDnsZones.cohovineyard.com</DNSname> <NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <! — - PartitionType:Application --> <Guid> f018941b-c899-4601-bfa7-5c017e9d31f3</Guid> <DNSname>DomainDnsZones.cohovineyard.com</DNSname>

502

<NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <! — - ForestRoot --> <Guid>89cf6b34-d753-32a8-da6b-6a8e04bc48a4</Guid> <DNSname>cohovineyard.com</DNSname> <NetBiosName>COHOVINEYARD</NetBiosName> <DcName></DcName> </Domain> </Forest>

AFTER editing (root domain name: cohowinery.com)
<Forest> <Domain> <!-— PartitionType:Application --> <Guid>59add6bb-d0e8-499e-82b9-8aaca5d3e18b</Guid> <DNSname>DomainDnsZones.sales.cohowinery.com</DNSname> <NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <Guid>89cf8ae3-f4a3-453b-ac5c-cb05a76bfa40</Guid> <DNSname>sales.cohowinery.com</DNSname> <NetBiosName>SALES</NetBiosName> <DcName></DcName> </Domain> <Domain> <! — - PartitionType:Application --> <Guid> f018941b-c899-4601-bfa7-5c017e9d31e7</Guid> <DNSname>ForestDnsZones.cohowinery.com</DNSname> <NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain>

503

<! — - PartitionType:Application --> <Guid> f018941b-c899-4601-bfa7-5c017e9d31f3</Guid> <DNSname>DomainDnsZones.cohowinery.com</DNSname> <NetBiosName></NetBiosName> <DcName></DcName> </Domain> <Domain> <! — - ForestRoot --> <Guid>89cf6b34-d753-32a8-da6b-6a8e04bc48a4</Guid> <DNSname>cohowinery.com</DNSname> <NetBiosName>COHOWINERY</NetBiosName> <DcName></DcName> </Domain> </Forest>

Note The current forest description must be available as the XML-encoded file Domainlist.xml that can be modified. Membership in the Local Administrators group (or write access to the domain rename C:\domren working directory) on the control station computer is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To edit the Domainlist.xml file 1. Use a simple text editor, such as Notepad.exe, to open the current forest description file Domainlist.xml that you created in Generate the Current Forest Description. 2. Edit the forest description file, replacing the current DNS or NetBIOS names of the domains and application directory partitions to be renamed with the planned new DNS or NetBIOS names. Note It is not necessary to change the NetBIOS name of a domain when its DNS name changes.

Renaming application directory partitions
In the previous sample forest description Domainlist.xml file, notice that there are two DNSname entries that are not domains. These directory partitions are labeled as follows:
<!-— PartitionType:Application -->

504

These directory partitions store DNS zone data. By default, application directory partitions can be used to store DNS zone data and Microsoft Telephony Application Programming Interface (TAPI) data in Active Directory Domain Services (AD DS). Other applications must be programmed to create and use application directory partitions in AD DS. Application directory partitions can exist anywhere in the domain hierarchy where a domain directory partition can exist, except for the forest root or tree root domain positions. However, when you rename a domain, an application directory partition that occurs below the renamed domain in the domain tree is not renamed automatically. You must take care to edit the names of application directory partitions if they occur below a renamed domain in the hierarchy.

DNS data
If you have Active Directory–integrated DNS that is running on a domain controller, the DNS server might have created one or more application directory partitions to store data for DNS zones. There is one DNS-specific application directory partition dedicated for each domain (named DomainDnsZones.<domain DNS name>, where <domain DNS name> is the name of the domain), and another DNS-specific application directory partition dedicated for the entire forest (named ForestDnsZones.<forest DNS name>, where <forest DNS name> is the name of the forest root domain). Important When an Active Directory forest root domain or other domain is renamed, the corresponding DNS-specific application directory partition must be renamed. If the DNSspecific application directory partition is not renamed, new DNS servers that are added to the network will not automatically load the DNS zones that are stored in the DNS-specific application directory partition, and therefore they will not function correctly. As you can see from the contents of the sample Domainlist.xml file before and after editing, the following three DNS-specific application directory partitions in the original forest …
DomainDnsZones.sales.cohovineyard.com DomainDnsZones.cohovineyard.com ForestDnsZones.cohovineyard.com

… are renamed to …
DomainDnsZones.sales.cohowinery.com DomainDnsZones.cohowinery.com ForestDnsZones.cohowinery.com

… in the new forest as a result of the domain name sales.cohovineyard.com that is being changed to sales.cohowinery.com and the forest root domain name cohovineyard.com being changed to cohowinery.com, respectively.

505

TAPI data
If you have a Microsoft TAPI dynamic directory for a domain that is hosted by AD DS, you may have created one or more application directory partitions (one for each domain) to store TAPI application data. There is one TAPI-specific application directory partition configured for each domain. When you rename an Active Directory domain, the corresponding TAPI-specific application directory partition is not renamed automatically. We recommend that you rename a TAPI-specific application directory partition when its corresponding domain name is changed. To rename application directory partitions 1. Examine the forest description file to determine if any application directory partitions in the forest must be renamed as a result of the domain DNS name changes that are being specified. 2. Consult the documentation for the application that created the application directory partition to see if the directory partition should be renamed. Any DNS name changes for application directory partitions must also be specified in the forest description file Domainlist.xml, along with the domain directory partition name changes.

Specifying the source domain controllers
In Generate Domain Rename Instructions, the Rendom.exe tool contacts one arbitrarily chosen domain controller in each domain of the forest to gather the information that is required for translating your new forest specification in the Domainlist.xml file into a sequence of required directory changes that areee encoded as a script to be run at each domain controller. As an option, you can specify a particular domain controller in each domain from which to pull the domainspecific information. To specify domain controllers for each renamed domain in domainlist.xml • In the field that is bounded by the <DcName></DcName> tags within each domain entry, type the DNS host name of the domain controller that you want to use. For example, to retrieve information for the domain sales.cohovineyard.com from the domain controller dc1.sales.cohovineyard.com, specify <DcName>dc1.sales.cohovineyard.com</DcName> within the domain entry for the renamed domain sales.cohowinery.com. (Recall that domain controller names do not change when the domain is renamed.)

Reviewing the new forest description
Verify that the domain name changes that you have specified in the forest description file Domainlist.xml yield the new forest structure that you want. You can use Rendom.exe to display the new forest structure that you specified in the Domainlist.xml file in a user-friendly format by using text indentation to reflect the domain hierarchy.

506

To review the new forest description in Domainlist.xml 1. Click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
rendom /showforest

This command simply displays the contents of the Domainlist.xml file in a format that is easier to read and in which you can better see the forest structure. Use this command each time that you make any changes to the Domainlist.xml file to verify that the forest structure looks as you intended. Note It is essential at this step to specify an accurate forest description that reflects the desired changes to the forest structure, because any error at this stage will result in an unintended forest structure when the domain rename operation is complete. If your target structure is not what you intended, you must perform the entire domain rename procedure again. Note To gather the information that is necessary to process the /showforest command-line option, Rendom.exe contacts the domain controller that is the current domain naming master in the target forest. The command might fail if the domain naming master is unavailable or unreachable from the control station.

Generate Domain Rename Instructions
You can use this procedure to generate domain rename instructions. In this procedure, you use the Rendom.exe tool to generate the domain rename instructions that are required to make your new target forest structure effective. Rendom.exe translates the new forest structure as specified in the edited forest description file that you prepared in Specify the New Forest Description into a sequence of directory update instructions that are run individually and remotely on each domain controller in the forest. The XML-encoded script that contains the domain rename instructions is written to the single-valued, octet-string attribute msDS-UpdateScript on the Partitions container object (cn=partitions,cn=configuration,dc=ForestRootDomain) in the configuration directory partition on the domain naming operations master. For more information about the exact directory changes that occur on the domain naming master, see “Preparing Domain Controllers for Domain Rename” in How Domain Rename Works (http://go.microsoft.com/fwlink/?LinkId=124104). Rendom.exe also generates a state file called Dclist.xml (the default name) and stores this file in the control station's working directory. The Dclist.xml state file is used to track the progress and state of each domain controller in the forest for the rest of the domain rename operation. The following is a sample Dclist.xml file that is generated for the two-domain forest in which there are two domain controllers named DC1 and DC2 in the cohovineyard.com domain and two domain controllers named DC3 and DC4 in the sales.cohovineyard.com domain.
<?xml version = “1.0”?>

507

<DcList> <Hash>zzzzzzzz</Hash> <Signature>zzzzzzzz</Signature>

<DC> <Name>DC1.cohovineyard.com</Name> <State>Initial</State> <LastError>0</LastError> <Password /> <LastErrorMsg /> <FatalErrorMsg /> <Retry></Retry> </DC> <DC> <Name>DC2.cohovineyard.com</Name> <State>Initial</State> <LastError>0</LastError> <Password /> <LastErrorMsg /> <FatalErrorMsg /> <Retry></Retry> </DC> <DC> <Name>DC3.sales.cohovineyard.com</Name> <State>Initial</State> <LastError>0</LastError> <Password /> <LastErrorMsg /> <FatalErrorMsg /> <Retry></Retry> </DC> <DC> <Name>DC4.sales.cohovineyard.com</Name> <State>Initial</State>

508

<LastError>0</LastError> <Password /> <LastErrorMsg /> <FatalErrorMsg /> <Retry></Retry> </DC> </DcList>

Notice that there is an entry for every domain controller in the forest in the Dclist.xml state file, and the state of each domain controller entry (the field that is bounded by the <State></State> tags) is set to “Initial” at this step. This state will change independently for each domain controller as it progresses through the rest of the domain rename operation. Ensure that the following conditions are in effect before you generate domain rename instructions: • The source domain controller must be available and reachable. Rendom contacts one arbitrarily chosen domain controller in each domain (or the domain controller that is designated for each domain in the <DCname></DCname> field in the Domainlist.xml file) to gather the information that is necessary to generate the domain rename instructions. The command might fail if a designated domain controller in a domain is unavailable or unreachable from the control station (or if a designated domain controller was not specified, if no domain controller in a domain is reachable from the control station). • The domain naming master must be available and reachable. Rendom writes the domain rename instructions to the Partitions container in the Configuration directory partition on the domain naming master, and Rendom gathers the information that is necessary to generate the state file Dclist.xml. The command might fail if the domain naming master is unavailable or unreachable from the control station. Membership in the Enterprise Admins group in the target forest (with a write access to the Partitions container object and the cross-reference objects that are its children in the configuration directory partition) and the Local Administrators group (or a write access to the domain rename C:\domren working directory) on the control station computer is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Note You can use credentials other than the credentials with which you are currently logged on. To use alternative credentials, use the /user and /pwd command-line switches of rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool. To generate the domain rename instructions and upload them to the domain naming master 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following to change to the working directory, and then press ENTER: 509

C:\domren

3. From within the working directory, type the following command, and then press ENTER:
rendom /upload

4. Verify that the state file Dclist.xml is created in the working directory and that it contains an entry for every domain controller in your forest.

Push Domain Rename Instructions to All Domain Controllers and Verify DNS Readiness
You can use this procedure to push domain rename instructions to all domain controllers and verify Domain Name System (DNS) readiness. In this procedure, you force Active Directory replication to push the domain rename instructions that were uploaded to the domain naming operations master in Generate Domain Rename Instructions to all domain controllers in the forest. In addition, you verify that the domain controller Locator (DC Locator) records that are registered in DNS by each domain controller for the new domain names have replicated to all DNS servers that are authoritative for those records.

Pushing domain rename instructions to all domain controllers
You can use Repadmin.exe tool to force Active Directory replication of directory changes on the domain naming master to all domain controllers in the forest. Note Forcing replication is not required, but it serves to accelerate the replication of the changes to the Partitions container in the configuration directory partition to all domain controllers in the forest. As an option, you can wait for replication to complete according to the usual replication intervals and delays that are characteristic of your forest. If the command in the following procedure completes successfully, the changes that originate at the domain naming master domain controller have replicated to every domain controller in the forest. If the command reports an error for some subset of the domain controllers in the forest, the replication must be reattempted for those failed domain controllers until all domain controllers in the forest have successfully received the changes from the domain naming master. Membership in the Enterprise Admins group in the target forest is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. 510

To force synchronization of changes made on the domain naming master to all domain controllers in the forest 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /syncall /d /e /P /q DomainNamingMaster

Note The repadmin command-line options are case sensitive. Note If read-only domain controllers (RODCs) are included in your domain, run this command one more time to ensure that the RODC new servicePrincipalName attribute is replicated to all the domain controllers in the forest.
Parameter Description

/syncall /d /e /P /q DomainNamingMaster

Synchronizes a specified domain controller with all replication partners. Identifies servers by distinguished name in messages. Enterprise, cross sites. Pushes changes outward from the home server. Quiet mode; suppresses callback messages. Specifies the DNS host name of the domain controller that is the current domain naming master for the forest.

If you do not know the DNS host name of the domain naming master, you can use the Dsquery.exe tool to discover it. Membership in the Enterprise Admins group in the target forest, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To discover the DNS host name of the domain naming master 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
Dsquery server -hasfsmo name

Parameter

Description

Dsquery server -hasfsmo

Finds the domain controller in Active Directory 511

Parameter

Description

Domain Services (AD DS) that holds the specified operations master (also known as flexible single master operations (FSMO)) role. name Specifies the Active Directory domain controller name.

Verifying DNS readiness
During domain rename, the service (SRV) resource records that are associated with the new domain name that are used by the domain controller Locator (DC Locator) are prepublished in the authoritative DNS servers by the Net Logon service that is running on the domain controllers of the domain. For domain controller location to be functional after domain rename, there are a subset of records whose presence at the authoritative DNS servers is critical for authentication and replication to take place. The following table lists the necessary resource records, in order of importance. Type CNAME Name of owner DsaGuid._msdcs.DnsForestName Explanation There must be one alias (CNAME) resource record associated with every domain controller in all authoritative DNS servers. This record ensures that replication will take place from that domain controller. There must be one service (SRV) resource record that pertains to the primary domain controller (PDC) on all authoritative DNS servers. This record ensures that authentication of users and computers is functioning. There must be at least one resource record that pertains to at least one global catalog server on all authoritative DNS servers. 512

SRV

_ldap._tcp.pdc._msdcs.DnsDomainName

SRV

_ldap._tcp.gc._msdcs.DnsForestName

This record ensures that authentication of users and computers is functioning. For example, one DNS server might contain a record of this type that is registered by one gobal catalog, while other DNS servers might contain the records of this type that are registered by other global catalogss. It is sufficient, temporarily, if there is at least one record of this type that is present on all authoritative DNS servers. The other records will eventually replicate to all authoritative DNS servers. SRV _ldap._tcp.dc._msdcs.DnsDomainName There must be at least one resource record pertaining to at least one domain controller on all authoritative DNS servers. This record ensures that authentication of users and computers is functioning. For example, one DNS server might contain a resource record of this type that is registered by one domain controller, while other DNS servers might contain the records of this type that are registered by other domain controllers. It is sufficient, temporarily, if there is at least one record of this type present on all authoritative DNS servers. The other records will eventually replicate to all authoritative DNS servers. 513

Note The word "must" in the context of this table means do not—under any circumstances— proceed with domain rename unless this requirement is fulfilled. The following two resource records are also required for authentication: • KDC: A service (SRV) resource record that is owned by _kerberos._tcp.dc._msdcs.DnsDomainName. • GcIpAddress: A host (A) resource record that is owned by _gc._msdcs.DnsForestName. However, because these resource records are closely linked with the global catalog and the domain controller service (SRV) resource records that are described in the table, it is sufficient to confirm the presence of the global catalog and the domain controller service (SRV) resource records to assume that these two records have also been prepublished. You can use the DcDiag.exe tool to confirm that the correct service (SRV) resource records that DC Locator uses have been registered in DNS. Membership in the Enterprise Admins group in the target forest, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To verify DNS records readiness 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command, and then press ENTER:
Dcdiag /test:DNS /DnsRecordRegistration /s:domaincontroller

For more information about dcdiag syntax and parameters, see Dcdiag Syntax (http://go.microsoft.com/fwlink/?LinkID=123103).

Verify Readiness of Domain Controllers
You can use this procedure to verify the readiness of domain controllers for a domain rename operation. In this procedure, you run a preparatory check on every domain controller in the forest to verify that the directory database at each domain controller in the forest is in a good state and ready to perform the directory modifications that are dictated by the domain rename instructions. You perform the verification by using the Rendom.exe tool to issue a remote procedure call (RPC) individually to each domain controller in the forest that is tracked by the state file Dclist.xml. The RPC causes each domain controller to verify that its directory replica is in a good state to perform the changes that are dictated by the domain rename instructions. For each domain controller that is successfully verified for readiness, Rendom updates the state field in the corresponding domain controller entry in the state file Dclist.xml to Prepared (<State>Prepared</State>).

514

Important All domain controllers must be in the Prepared state before domain rename instructions can be run. Ensure that the following conditions are in effect before you use Rendom.exe to verify that your domain controllers are ready for the domain rename operation: • The preparatory changes that are made to the Partitions container of the forest’s domain naming operations master during the generation of domain rename instructions must have replicated to every domain controller in the forest. This status is checked for and enforced by Rendom.exe during this step. • Service (SRV) resource records, which are required for domain controller location of the renamed domains, must be registered in Domain Name System (DNS) and they must have replicated to all DNS servers. Membership in the Enterprise Admins group in the target forest (with write access to the Partitions container object and the cross-reference objects that are its children in the configuration directory partition) and the Local Administrators group (or write access to the domain rename C:\domren working directory) on the control station computer is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Note You can use credentials other than the credentials with which you are currently logged on. To use alternative credentials, use the /user and /pwd command-line switches of rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool. To verify the readiness of domain controllers in the forest 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command to change to the working directory, and then press ENTER:
C:\domren

3. From within the working directory, type the following command, and then press ENTER:
rendom /prepare

4. After the command finishes, examine the state file Dclist.xml to determine whether all domain controllers achieved the Prepared state. If not, repeat step 2 in this procedure until all domain controllers achieve the Prepared state. Note Each time that it runs, the Rendom tool consults the Dclist.xml state file and, it does not connect to and verify the domain controllers that are already in the Prepared state. Therefore, no redundant operations are performed when you run this command repeatedly.

515

In a large forest with a large number of domain controllers, it is very likely that all domain controllers cannot be reached from the control station at the same time. In other words, it is not likely that all domain controllers that are tracked by the state file Dclist.xml will reach the Prepared state in a single running of the rendom /prepare command. Therefore, multiple invocations of this command might be necessary to make incremental progress with groups of domain controllers that reach the Prepared state at the same time. If you determine that—for any reason—it is impossible to make any further progress with a specific domain controller, you can remove the entry for that domain controller (bounded by the <DC></DC> tags) from the Dclist.xml file by simply editing the state file with a text editor. Remember that, when a domain controller is removed in this manner from participating in the domain rename procedure, it must be retired (that is, Active Directory Domain Services (AD DS) must be removed from domain controller) in the new forest after the domain rename operation is complete. Note Make sure that you save a copy of the state file Dclist.xml every time before you edit by using a text editor. This makes an easy fallback and recovery possible in case you make an error in editing the file. As Rendom.exe executes the various command-line options, the command execution log is cumulatively captured in a log file named Rendom.log (the default name) in the current working directory (C:\domren). When execution of a Rendom.exe command fails, examination of this log file can yield valuable information about the actual tasks that the tool performed, and at what stage or on which domain controller a problem occurred.

Run Domain Rename Instructions
You can use this procedure to execute domain rename instructions. In this procedure, you execute the domain rename instructions that are contained in the special script that is uploaded to the msDS-UpdateScript attribute on the Partitions container on every domain controller in the forest. To execute the script, the control station computer issues a remote procedure call (RPC) to each domain controller in the forest individually, which causes each domain controller to execute the domain rename instructions and then restart automatically after it runs the instructions successfully. At the end of this procedure, every domain controller that is tracked by the state file dclist.xml will be in one of two final states: • Done, which means that the domain controller successfully completed the domain rename operation. • Error, which means that the domain controller encountered an irrecoverable error and did not complete the domain rename operation. In other words, if a domain controller successfully executes the domain rename instructions, it restarts automatically and its corresponding state for the domain controller entry in the state file is updated to read <State>Done</State>. But, if a fatal or irrecoverable error is encountered on a domain controller while you attempt to execute the domain rename instructions, its corresponding state for the domain controller entry in the state file is updated to read <State>Error</State>. For 516

the Error state, the error code is written to the last error field <LastError></LastError> and a corresponding error message is written to the <FatalErrorMsg></FatalErrorMsg> field. The rendom command must be repeated until all domain controllers have either successfully executed the domain rename or you have established that one or more domain controllers are unreachable and will be removed from the forest. Important This step will cause a temporary disruption in service while the domain controllers are running the domain rename instructions and restarting after they run the instructions successfully. The Active Directory Domain Services (AD DS) service in the forest has not been disrupted up to this point in the domain rename operation. Important All domain controllers in the forest must be in the Prepared state, as indicated by the state field (<State>Prepared</State>) in the state file Dclist.xml. This state is checked for and enforced by rendom at this step. Membership in the Enterprise Admins group in the target forest (with write access to the Partitions container object and the cross-reference objects that are its children in the configuration directory partition) and the Local Administrators group (or write access to the domain rename C:\domren working directory) on the control station computer is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Note You can use credentials other than the credentials with which you are currently logged on. To use alternative credentials, use the /user and /pwd command-line switches of rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool. To run the domain rename instructions on all domain controllers 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command to change to the working directory, and then press ENTER:
C:\domren

3. From within the working directory, type the following command, and then press ENTER:
rendom /execute

4. When the command has finished running, examine the state file Dclist.xml to determine whether all domain controllers have reached either the Done state or the Error state. 5. If the Dclist.xml file shows any domain controllers as remaining in the Prepared state, repeat step 2 in this procedure as many times as necessary until the stopping criterion is met. 517

Important The stopping criterion for the domain rename operation is that every domain controller in the forest has reached one of the two final states of Done or Error in the Dclist.xml state file. Note Each time that you run it, the rendom /execute command consults the Dclist.xml state file and skips connecting to the domain controllers that are already in the Done or Error state. Therefore, no redundant operations are performed if you repeatedly attempt this command. If you determine that an error that has caused a domain controller to reach the Error state in the Cclist.xml file is actually a recoverable error and you think that progress can be made on that domain controller by trying to run the domain rename instructions again, you can force the rendom /execute command to run again by issuing the RPC to that domain controller (instead of skipping it) as described in the following procedure. To force rendom /execute to reissue the RPC to a domain controller in the Error state 1. On the control station, navigate to the working directory C:\domren, and using a simple text editor, such as Notepad.exe, open the Dclist.xml file. 2. In the Dclist.xml file, locate the <Retry></Retry> field in the domain controller entry for the domain controller that you think should be reissued the RPC, and then edit the Dclist.xml file so that the field reads <Retry>yes</Retry> for that entry. 3. On the control station, click Start, click Run, type cmd, and then click OK. 4. At the command prompt, type the following command to change to the working directory, and then press ENTER:
C:\domren

5. From within the working directory, type the following command, and then press ENTER:
rendom /execute

Running the rendom /execute command reissues the execute-specific RPC to that domain controller. When all the domain controllers are in either the Done or Error state (there should be no domain controller in the Prepared state), declaring the execution of the domain rename instructions to be complete is at your discretion. You can continue to retry execution attempts on domain controllers that are in the Error state if you think that they will eventually succeed. However, when you declare that the execution of the domain rename instructions is: Complete, and you will not retry the rendom /execute command, you must remove AD DS from all domain controllers that are still in the Error state. For detailed step-by-step instructions to remove the AD DS server role, see the Step-by-Step Guide for Windows Server 2008 Active Directory Domain Services Installation and Removal (http://go.microsoft.com/fwlink/?LinkID=86716). 518

Note The Domain Name System (DNS) host names of the domain controllers in the renamed domains do not change automatically as a result of the domain rename operation. In other words, the DNS suffix in the fully qualified DNS host name of a domain controller in the renamed domain will continue to reflect the old domain name. You can use a special domain controller rename procedure, which you run as a separate post-domain-rename task, to change the DNS host name of a domain controller so that it conforms to the DNS name of the domain to which it is joined. For information about renaming domain controllers, see Renaming a Domain Controller.

Exchange-Specific Steps: Update the Exchange Configuration and Restart Exchange Servers
You can use this procedure to update the Exchange configuration and restart Exchange servers for a domain rename operation. If the domain contains servers running Microsoft Exchange Server 2003 Service Pack 1 (SP1), before you continue with step 9, run the Exchange Domain Rename Fix-up Tool (XDR-fixup). Then, restart all the servers running Exchange twice. For more information, see Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup) (http://go.microsoft.com/fwlink/?LinkID=123144). Important The Windows Server 2008 domain rename operation is not supported in an Active Directory forest that contains Exchange Server 2003, Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, or Exchange Server 2007 SP1.

Unfreeze the Forest Configuration
You can use this procedure to unfreeze the forest configuration after a domain rename operation. After you generated the domain rename instructions (see Generate Domain Rename Instructions), your forest configuration was frozen with respect to certain types of changes. In this frozen configuration, addition or removal of domains, addition or removal of domain controllers (DCs), and addition or removal of trusts were not allowed within the forest. For more information, see Freeze the Forest Configuration. In this procedure, you use the rendom command to unfreeze the forest so that changes that were not allowed can once again be made.

519

Important All the procedures in Run Domain Rename Instructions, including the automatic domain controller restart, must have been completed on all domain controllers in the renamed domains. Membership in the Enterprise Admins group in the target forest (with write access to the Partitions container object) is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Note You can use credentials other than the credentials with which you are currently logged on. To use alternative credentials, use the /user and /pwd command-line switches of Rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool. To unfreeze the forest configuration 1. Restart the control station computer twice to ensure that all services that are running on it learn of the new name (Domain Name System (DNS) name or NetBIOS name) of the domain of which the control station is a member. Do not restart the control station by turning its power off and then back on. 2. On the control station, click Start, click Run, type cmd, and then click OK. 3. At the command prompt, type the following command to change to the working directory, and then press ENTER:
C:\domren

4. From within the working directory, type the following command, and then press ENTER:
rendom /end

The rendom /end command connects to the domain controller that holds the domain naming operations master role and removes the attribute msDS-UpdateScript on the Partitions container.

Re-establish External Trusts
You can use this procedure to re-establish external trusts after a domain rename operation. All intraforest shortcut trusts within the forest in which the domain rename occurred are automatically adjusted during the domain rename operation so that they continue to work. However, as a result of the domain name changes in your forest, any external trust relationships that your forest has with other forests (including trusts across forests) will not be valid. Therefore, they must be reestablished. In particular, when a domain in your forest is renamed, the following trust relationships are not valid:

520

• Any interforest trust relationship that is established at the forest root level (a trust across forests). • Any external trust relationship with a domain in another forest. All external trusts from or to the forest in which the domain rename operation occurred must be deleted and recreated. You can use the Active Directory Domains and Trusts Microsoft Management Console (MMC) snap-in to delete and recreate all such trust relationships. For more information, see Administering Domain and Forest Trusts.

Fix Group Policy Objects and Links
You can use this procedure to fix Group Policy objects (GPOs) and links after a domain rename operation. In this procedure, you use the Gpfixup.exe command-line tool to repair GPOs as well as GPO references in each renamed domain. It is necessary to repair the GPOs and the Group Policy links after a domain rename operation to update the old domain name that is embedded in these GPOs and their links. This procedure is necessary so that Group Policy continues to function normally in the new forest after the domain rename operation is complete. The Gpfixup.exe tool also repairs any Group Policy–based Software Installation and Maintenance data (such as Software Distribution Point network paths), if they are present in Active Directory Domain Services (AD DS), so that managed software deployment continues to work in your environment. The GPO and link fix-up tool must be run once in each renamed domain. There is no GPO and link fix-up required that corresponds to renamed application directory partitions because you cannot apply Group Policy to an application directory partition. Important The GPO/link fix-up procedure does not fix any interdomain GPO links that might exist in your forest. Any existing interdomain GPO links must be either removed or reconfigured so that they can work properly. In addition, this fix-up procedure does not repair network paths for Software Distribution Points (present in AD DS) that are external to the domain. As a best practice, do not use GPO links that cross domain boundaries. Before you repair GPOs, ensure that the following conditions are satisfied: • All procedures that are described in Run Domain Rename Instructions, that include the automatic domain controller restart, must have been completed on all domain controllers in the renamed domains. • The domain controller with the primary domain controller (PDC) emulator operations master role in a renamed domain must have successfully completed the domain rename operation, and it must have reached the final "Done" state as described in Run Domain Rename Instructions. • The control station computer must have been restarted twice, as described in Unfreeze the Forest Configuration. • All member servers in the domain that host Software Distribution Points (network locations from which users deploy managed software in your environment) must have been restarted twice, as described in Run Domain Rename Instructions. This prerequisite step is extremely 521

important and necessary for the Software Installation and Maintenance data fix-up to work correctly. Membership in the Enterprise Admins group in the target forest is the minimum required to complete these procedures. The access check that you perform in this procedure requires that you have write access to the gpLink attribute on the site, domain, and organizational unit (OU) objects, as well as write access to the GPOs themselves. Note You can use credentials other than the credentials with which you are currently logged on. To use alternative credentials, use the /user and /pwd command-line switches of gpfixup, as described in Appendix B: Command-Line Syntax for the Gpfixup Tool. To fix up GPOs and GPO references 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command to change to the working directory, and then press ENTER:
C:\domren

3. From within the working directory, type the following command, and then press ENTER. The entire command must be typed on a single line, although it is shown on multiple lines for clarity.
gpfixup /olddns:OldDomainDnsName /newdns:NewDomainDNSName /oldnb:OldDomainNetBIOSName /newnb:NewDomainNetBIOSName /dc:DcDnsName 2>&1 >gpfixup.log

Note The command-line parameters /oldnb and /newnb are required only if the NetBIOS name of the domain changed. Otherwise, you can omit these parameters from the command line for Gpfixup. The output of the command—both status or error output—is saved to the file Gpfixup.log, which you can display periodically to monitor the progress of the command. 4. To force replication of the Group Policy fix-up changes that are made at the domain controller that is named in DcDNSName in step 3 of this procedure to the rest of the domain controllers in the renamed domain, type the following command, and then press ENTER:
repadmin /syncall /d /e /P /q DcDnsName NewDomainDN

Where: • DcDnsName is the Domain Name System (DNS) host name of the domain controller that was targeted by the gpfixup command. •
NewDomainDN

is the distinguished name that corresponds to the new DNS name of 522

the renamed domain. 5. Repeat steps 2 and 3 in this procedure for every renamed domain. You can enter the commands in sequence for each renamed domain. For example, using the sample forest and domain name changes in Specify the New Forest Description, you run the gpfixup command twice—once for the renamed cohovineyard.com domain and once for the sales.cohovineyard.com domain, as indicated in the following example:
gpfixup /olddns:cohovineyard.com /oldnb:cohovineyard /newdns:cohowinery.com

/newnb:cohowinery 2>&1 >gpfixup1.log

/dc:dc1.cohovineyard.com

repadmin /syncall /d /e /P /q dc1.cohovineyard.com dc=cohowinery,dc=com gpfixup /olddns:sales.cohovineyard.com /dc:dc3.sales.cohovineyard.com /newdns:sales.cohowinery.com

2>&1 >gpfixup2.log

repadmin /syncall /d /e /P /q dc3.sales.cohovineyard.com dc=sales,dc=cohowinery,dc=com

Important Run the gpfixup command only once for each renamed domain. Do not run it for renamed application directory partitions. Note The DNS host names for the domain controllers in the renamed domains that are used in these command invocations still reflect the old DNS name for the domain. As mentioned earlier, the DNS host name of a domain controller in a renamed domain does not change automatically as a result of the domain name change.
Parameter Description

gpfixup

Fixes domain name dependencies in Group Policy objects and Group Policy links after a domain rename operation. Specifies the old DNS name of the renamed domain. Specifies the new DNS name of the renamed domain. Specifies the old NETBIOS name of the renamed domain. Specifies the new NETBIOS name of the renamed domain. Contains status or error output of the command. 523

/olddns:OldDomainDnsName /newdns:NewDomainDNSName /oldnb:OldDomainNetBIOSName /newnb:NewDomainNetBIOSName /dc:DcDnsName 2>&1 >gpfixup.log

Parameter

Description

Completing the Domain Rename Operation
This task provides information and procedures for completing the domain rename operation. After you complete the domain rename procedures in Performing the Domain Rename Operation, complete the instructions in this task to be sure that all functionality that relies on the accurate domain name has been addressed with any needed related tasks. Task requirements The following is required to perform the procedures for this task: • • • • • Rendom.exe Verify Certificate Security Perform Miscellaneous Tasks Back Up Domain Controllers Restart Member Computers To complete this task, perform the following procedures:

• Exchange-Specific Steps: Verify the Exchange Rename and Update Active Directory Connector • • Perform Attribute Cleanup Rename Domain Controllers

Verify Certificate Security
You can use this procedure to verify certificate security after you complete a domain rename operation. If you use enterprise certificates, perform all the following procedures after the domain rename operation is complete.

Preparing URLs for CRL distribution point and Authority Information Access (AIA) extensions after a domain rename
To ensure that the old certificates function properly after a domain rename operation, make an alias (CNAME) resource record Domain Name System (DNS) entry that redirects the old Hypertext Transfer Protocol (HTTP) server (that services the Certificate Revocation List (CRL) of the certification authority (CA)) name query to the new DNS name for the server. This redirection 524

causes the HTTP URLs in the old certificates to be valid. Client computers can then obtain CRLs and CA certificates for verification. Note You can remove the alias (CNAME) resource record after you know that the existing certificates have been renewed. Note If you only have Lightweight Directory Access Protocol (LDAP) URLs in the certificates, all the previously issued certificates will no longer be validated. The only workaround for correcting the LDAP CRL distribution point and AIA pointers is to renew the entire CA hierarchy and reissue the End Entity certificates. Expect public key infrastructure (PKI) downtime until these issues are resolved. Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To configure the redirecting alias DNS entry 1. Open the DNS Manager snap-in. To open DNS Manager, click Start, click Administrative Tools, and then click DNS. 2. In the console tree, expand the DNS server node, and locate the old DNS zone. 3. Right-click the old DNS zone, and then click New Alias (CNAME). 4. In Alias name, type the original fully qualified domain name (FQDN) of the HTTP server. 5. In Fully qualified domain name for target host, type the new FQDN of the HTTP server, and then click OK. At this point you can test the redirection by pinging the FQDN of the old HTTP server. The ping should be remapped to the new FQDN of the HTTP server.

Verifying the use of UPNs
Authentication protocols, such as Kerberos (Smart Card Logon), require the user principal name (UPN) in the user certificate to match the UPN in the user account (implicitly or explicitly) in Active Directory Domain Services (AD DS). You should be aware of the differences in behavior between implicit and explicit UPNs. • Implicit UPN: If a user account in AD DS does not have an explicitly assigned value for its UPN attribute, it is assumed to have an implicit UPN for authentication purposes that is based on the DNS name of the domain in which the account exists. When the DNS name of a domain changes as a result of the domain rename operation, the implicit UPNs of all user accounts in the domain also change. Both the old and the new implicit UPN forms will be accepted for authentication until the attribute cleanup procedures are complete (see Perform Attribute Cleanup). After the attribute cleanup procedures are complete, only the new implicit UPN form will be accepted. 525

Note This behavior implies that if you want to continue using implicit UPNs for user accounts, you must reissue all existing authentication certificates after the DNS name of a domain has changed and before you perform the attribute cleanup procedures. • Explicit UPN: If a user account in AD DS has an explicitly assigned value for its UPN attribute, it is said to have an explicit UPN that can be used for authentication purposes. When the DNS name of a domain changes as a result of the domain rename operation, the explicit UPNs of user accounts in the domain are not affected. Therefore, if you are using explicit UPNs for user accounts, no maintenance is necessary after the domain rename operation.

Enabling certificate enrollment in a renamed domain
• To enable certificate enrollment using either autoenrollment or the Certificates Microsoft Management Console (MMC) snap-in in the new domain, you have to make a small change in AD DS to the Enrollment Services Container in the configuration directory partition (cn=Enrollment Services,cn=Public Key Services, cn=Services,cn=Configuration,dc=ForestRootDomain). The CA object in this container has a dNSHostName attribute that still contains the old DNS name of the CA computer. You can use the following Microsoft Visual Basic® script to change the value of this attribute, as follows:
Container = “LDAP://CN=YOURCA,CN=Enrollment Services,CN=Public Key Services, CN=Services,CN=Configuration,DC=YoursubDomain,DC=YourDomain,DC=com” Set obj = GetObject(container) Obj.dnshostname = “NEWDNSNAMEOFTHECAMACHINE” Obj.setinfo

Note You must perform this procedure for all the CAs in your domain. Also note that the container name depends on your domain configuration. • You must also change the registry on the CA computer to reflect the new DNS name for the CA computer. Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To update the DNS name of the CA computer 1. On the CA computer, click Start, click Run, type regedit to open the Registry Editor, and then locate the entry CAServerName under 526

HKLM\System\CurrentControlSet\CertSvc\Configuration\YourCAName. 2. Change the value in CAServerName to correspond to the new DNS host name. • To enable proper Web enrollment for the user, you must also update the file that is used by the Active Server Pages (ASPs) for Web enrollment. The following change must be made on all the CA computers in your domain. Membership in Account Operators, Domain Admins, or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. To update the Web enrollment file 1. On the CA computer, search for the Certdat.inc file. If you have used default installation settings, this file should be located in %windir%\system32\certsrv directory. 2. Open the file, which appears as follows:
<%' CODEPAGE=65001 'UTF-8%> <%' certdat.inc - (CERT)srv web - global (DAT)a ' Copyright (C) Microsoft Corporation, 1998 - 1999 %> <%' default values for the certificate request sDefaultCompany="" sDefaultOrgUnit="" sDefaultLocality="" sDefaultState="" sDefaultCountry=""

' global state sServerType="Enterprise" 'vs StandAlone sServerConfig="OLDDNSNAME\YourCAName" sServerDisplayName="YourCAName" nPendingTimeoutDays=10

3. Change the SServerConfig entry so that it has the NewDNSName of the CA computer. • If the CA was installed with the shared folder option (which is available only if the server was upgraded to Windows Server 2008from Windows Server 2003), the file Certsrv.txt (under the shared folder) should be edited to reflect the new DNS name of the CA computer. Save a copy of this file before you edit it, open the file by using Notepad.exe, make the change to the DNS name of the CA computer, and then save the file.

527

• If you have a Web proxy computer (for CA Web pages) whose DNS host name changed as a result of the domain rename operation, you have to make changes to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration Under this key there is a value named WebClientCAMachine that holds the DNS name of the CA computer. Change this value to correspond to the new DNS name. To update the Netscape revocation check mechanism • On all computers where Web pages for the CA reside (for example, on the Web proxy and the CA computers) there is a file named nsrev_CANAME.asp that contains the DNS host name of the CA computer that is used by the Netscape revocation checking mechanism. Search for this file, and change the DNS host name of the CA computer that is embedded in the file. If you have used the default installations settings, this file will be in the folder %Windir %\system32\certsrv\certenroll and its content looks like the following.
<% Response.ContentType = "application/x-netscape-revocation" serialnumber = Request.QueryString set Admin = Server.CreateObject("CertificateAuthority.Admin") stat = Admin.IsValidCertificate("CAMachineDnsHostname\CANAME", serialnumber) if stat = 3 then Response.Write("0") else Response.Write("1") end if %>

Open this file with Notepad.exe, and change CAMachineDnsHostName to correspond to the new DNS host name.

Verifying the validity of CRL distribution point and AIA extensions
CRL distribution point and AIA extensions can be hard coded. Therefore, the extension URLs will not reflect the new DNS name of the CA computer. First, check to see whether the extensions are hard coded, and, if they are, you must change the URL to reflect the new DNS name. You must perform this procedure on every CA computer in each renamed domain. The Manage CA permission on the CA computer is the minimum required to complete this procedure. Manage CA is a special privilege that you can configure with the Certification Authority snap-in. To check whether the CRL distribution point and AIA extensions are flexible 1. Open the Certification Authority snap-in. To open Certification Authority, see Add the Certificates Snap-in to an MMC (http://go.microsoft.com/fwlink/?LinkId=124114). 2. Right-click the CA name, and then click Properties. 3. On the Extensions tab, check the flexibility of the CRL distribution point and AIA 528

extensions, as follows: a. Flexible extensions have the following format: http://<ServerDNSName>/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed >.crl b. Hard-coded extensions have the following format: http://mydnsname.mycompanyname.com/certenroll/<CAName><CRLNameSuffix><De ltaCRLAllowed>.crl 4. If the CRL distribution point and AIA extensions are flexible, you do not have to change the extensions. 5. If the CRL distribution point and AIA extensions are not flexible, change the extension URLs to reflect the new DNS name of the CA computer. 6. Repeat this procedure for every CA computer in the domain.

Renewing subordinate and issuing CA certificates
After all the preceding CA-related procedures have been performed on all CA computers, you can renew certificates to update the CRL distribution point and AIA locations in the CA certificate. Renew all subordinate and issuing CA certificates in hierarchical order. In addition, update Group Policy on all the computers to ensure that they have new root CA certificates.

Publish new CRLs
To publish new Delta and Base CRLs, run the following command on all the CA computers in the renamed domain:
Certutil.exe –crl

Updating domain controller certificates
The domain controller certificates have to be updated so that any authentication mechanism that is based on certificates (for example, replication and Smart Card through Kerberos) continues to work. To update these certificates, if template-based autoenrollment is set before the domain rename operation, increment the version number for Domain Controller Authentication and Directory E-mail Replication Certificate templates to force re-enrollment. Otherwise, use Group Policy to set Machine Based Autoenrollment. The domain controllers will re-enroll and supersede the existing V1 Domain Controller Certificate. You might also want to increase the version number on other templates (particularly the templates that are related with authentication) to set autoenrollment for the users and their computers. Fix Cross and Qualified Subordination Certificates and name constraints. For more information, see Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 (http://go.microsoft.com/fwlink/?LinkID=123176).

529

Changing the user identity for the NDES add-on
If the Network Device Enrollment Services (NDES) add-on for Microsoft Certificate Services is installed, you might have to change the identity of the user under whose context the NDES process was created. For example, if NDES was originally running with the identity OriginalDomainName\UserName, after domain rename operation, Internet Information Services (IIS) will attempt to start the process with the same identity. (The IIS metabase is not altered during the domain rename operation.) You can change this identity in IIS. To change the user identity for NDES in IIS 1. In the IIS MMC snap-in, browse to Application pools. 2. Under Application pools, right-click the folder for NDES, and then click Properties. 3. On the Identity tab, change the identity for NDES to correspond to the new domain name.

Perform Miscellaneous Tasks
You can use this procedure to perform miscellaneous tasks after a domain rename procedure. There are a number of miscellaneous follow-up tasks that you have to perform after the core domain rename tasks are complete. There is no particular order in which these tasks have to be performed. • Publish service connection points for renamed TAPI-specific application directory partitions. If you renamed Telephony Application Programming Interface (TAPI)–specific application directory partitions as part of specifying the new forest description procedure (Specify the New Forest Description), you have to publish service connection points in Active Directory Domain Services (AD DS) for the new name of the application directory partition so that TAPI clients can locate it. At the same time, you can remove the service connection points for the old name of the application directory partition. For example, suppose that you had a TAPI-specific application partition named mstapi.cohovineyard.com that was configured for the domain cohovineyard.com. As a result of the Domain Name System (DNS) name of the domain changing to cohowinery.com, you renamed the corresponding application directory partition to mstapi.cohowinery.com during the domain rename operation. You should now remove the service connection point for the old application directory partition name mstapi.cohovineyard.com by running the following command from a command prompt on the control station computer:
tapicfg removescp /directory:mstapi.cohovineyard.com /domain:cohowinery.com

530

Then, publish a service connection point for the new application directory partition name mstapi.cohowinery.com by running the following command from a command prompt on the control station:
tapicfg publishscp /directory:mstapi.cohowinery.com /domain:cohowinery.com /forcedefault



Orchestrate password reset for Digest authentication.

A Digest authentication mechanism uses the DNS domain name as the realm, which is then used to precompute the Digest user password hash that is stored in AD DS. If you are using Digest authentication in a domain that was renamed by the domain rename operation, a user in that domain will not be able to use Digest authentication until the user password is changed. If you are using Digest authentication in a domain that is renamed, you must do something to cause a password reset to occur. For example, you could do the following: • After you complete all the procedures in Run Domain Rename Instructions, (the domain rename instructions have all been followed and domain controllers have restarted in a renamed domain), expire all user passwords by changing domain password policy in the renamed domain. • Send out e-mail that warns users that they must change their passwords immediately after they reboot their computers twice (as described in Restart Member Computers). Users change their passwords by pressing Ctrl+Alt+Del. • Remove any redundant interdomain trusts within your forest. If you performed a forest restructure operation in which the existing domains were rearranged into a different tree structure, you would have created the necessary shortcut trusts to preserve complete trust between all the domains in your new forest, as described in "Pre-Creating Parent-Child Trust Relationships for a Restructured Forest" in Create Necessary Shortcut Trust Relationships. This type of a restructure can result in one or more parent-child or tree-root trust relationships remaining in your forest that reflect the old domain structure and are no longer required. Although their presence does no harm, you can use the Active Directory Domains and Trusts snap-in to remove these redundant trust relationships after the domain rename operation is complete. For more information, see Active Directory Domains and Trusts (http://go.microsoft.com/fwlink/?LinkId=124088). • Fix Start menu shortcuts for Domain Security Policy and Domain Controller Security Policy Microsoft Management Console (MMC) snap-ins.

1. Click Start, click Programs, and then click Administrative Tools. 2. Right-click Domain Security Policy, and then click Properties. 3. Modify the Target field to replace the old distinguished name of the domain that appears as part of the /gpobject: parameter with the new distinguished name of the domain. 4. Click OK. Note 531

For example, if you renamed the domain cohovineyard.com to cohowinery.com, the /gpobject: parameter will have to be changed from /gpobject:"LDAP://CN={31B2F340-016D-11D2-945F00C04FB984F9},CN=Policies,CN=System,DC=cohovineyard,DC=com" to /gpobject:"LDAP://CN={31B2F340-016D-11D2-945F00C04FB984F9},CN=Policies,CN=System,DC=cohowinery,DC=com". 5. To fix the Domain Controller Security Policy snap-in shortcut, follow steps 1 through 4 above, but select Domain Controller Security Policy in step 2. Note For example, if you renamed the domain msn.com to msnzone.com, the /gpobject: parameter will have to be changed from /gpobject:"LDAP://CN= {6AC1786C-016F-11D2-945F00C04fB984F9},CN=Policies,CN=System,DC=cohovineyard,DC=com" to /gpobject:"LDAP://CN= {6AC1786C-016F-11D2-945F00C04fB984F9},CN=Policies,CN=System,DC=cohowinery,DC=com". • Remove the Group Policy to set primary DNS suffix of member computers in renamed domains. If you followed the recommendations to avoid excess replication due to member computers being renamed in a large domain, as described in "Configuring Member Computers for Host Name Changes in Large Deployments" in Configure Member Computers for Host Name Changes, you might have configured and applied a Group Policy setting Primary DNS Suffix to member computers in your renamed domains. Because the intended purpose of this Group Policy setting has now been served, it can be removed. To remove this Group Policy setting, follow steps 1 through 5 of the procedure "Apply Group Policy to Set the Primary DNS Suffix" in Configure Member Computers for Host Name Changes, click Disabled, and then click OK. • Remove DNS zones that are no longer needed. As a result of the domain DNS name changes that occurred during the domain rename operation, some of the DNS zones in your DNS infrastructure might no longer be necessary. For example, if there was a DNS zone with a name that matched the old DNS name of a renamed domain, there might be no more DNS resource records (service (SRV), host (A), and pointer (PTR) resource records) with the old domain suffix that have to be registered with DNS. In this case, you can remove these DNS zones that are no longer necessary.

Back Up Domain Controllers
You can use this procedure to back up domain controllers after a domain rename operation. As a result of the domain rename operation, the content of the Active Directory database, system registry, and Group Policy objects (GPOs) on the domain controllers change. Therefore, the existing backups that you have taken for the domain controllers are no longer valid. • Back up system state 532

Perform a full system state backup of all domain controllers in the forest so that you have a recoverable backup state. For more information, see the Step-by-Step Guide for Windows Server 2008 Active Directory Domain Services Backup and Recovery (http://go.microsoft.com/fwlink/?LinkId=93077). • Back up GPOs If you use Group Policy, consider installing the Group Policy Management Console (GPMC). For more information, see GPMC (http://go.microsoft.com/fwlink/?LinkID=123307). GPMC makes Group Policy easier to use, and it adds functional improvements such as the ability to back up GPOs independently of the rest of Active Directory Domain Services (AD DS). GPOs that you back up with GPMC before the domain rename operation cannot be restored after domain rename. Therefore, we recommend that after a domain rename operation, you use GPMC to back up all the GPOs again. Note Saved GPMCs for a domain will no longer work after you rename a domain. If you want to use saved GPMCs, you have to re-create them after the domain rename operation.

Restart Member Computers
You can use this procedure to restart member computers after a domain rename operation. After the domains are renamed, you have to create a process by which all member computers in the renamed domains in your forest recognize and propagate the domain name changes to all applications and services that are running on member computers. You can do this by notifying all users to restart their computers (the member computers) to cause those computers to pick up the domain name changes. Important When the member computers are restarted, their Domain Name System (DNS) host names will also change after the restart as a result of the fact that their primary DNS suffix changes as a result of the name change of the domain of which they are members. The primary DNS suffix of a member computer in an Active Directory domain is, by default, configured to change automatically when domain membership of the computer changes. If you have very large domains whose DNS name was changed by the domain rename operation and these domains have a large number of member computers, you might observe a large replication storm and a surge in network traffic as a result of the member computer restarts. For information about how to avoid excess replication under these conditions, see Configure Member Computers for Host Name Changes. Perform the following tasks after the domain rename operation: • Restart all member computers twice. Restart twice all member workstations, member servers, and standalone servers (excluding domain controllers) that are running Windows 2000, Windows XP, Windows Server 2003, and 533

Windows Server 2008 in the renamed domains in your forest. When you restart these computers twice, this ensures that each member computer learns of the domain name changes and propagates the changes to all applications and services that are running on the member computer. Note Each computer must be restarted by logging into the computer and by using the Shutdown/Restart administrative option. Computers must not be restarted by turning off the computer’s power and then turning it back on. Note Member computers on a wired local area network (LAN) can simply be restarted twice. Member computers on a wireless LAN should be connected to a wired network while you perform the two required restarts. If that is not possible, eject the wireless network card and then reinsert it after logon before each restart. • Unjoin and then join any remote computers that connect to the renamed domain through a remote connection, such as dial-up and virtual private network (VPN). If there are any remote computers that are members of a renamed domain that connect to the domain through remote connection mechanisms such dial-up lines or VPNs, you will have to unjoin each member computer from the old domain name and then rejoin it to the new domain name.

Exchange-Specific Steps: Verify the Exchange Rename and Update Active Directory Connector
You can use this procedure to verify the Exchange rename and update the Active Directory Connector after a domain rename operation. If the domain contains Exchange Server 2003 Service Pack 1 (SP1) servers, follow the steps to verify the Exchange rename and update Active Directory Connector. For more information, see Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup) (http://go.microsoft.com/fwlink/?LinkID=123322). Important The Windows Server 2008 domain rename operation is not supported in an Active Directory forest that contains Exchange Server 2003, Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, or Exchange Server 2007 SP1.

Perform Attribute Cleanup
You can use this procedure to perform attribute cleanup after a domain rename operation. This post-domain-rename cleanup procedure removes all values of the msDS-DnsRootAlias and 534

msDS-UpdateScript attributes from Active Directory Domain Services (AD DS) that were written during the domain rename operation. Important Perform this cleanup procedure only after all member computers in the renamed domains have been restarted as described in Restart Member Computers. If smart card logon is used in your environment, make sure that all authentication certificates have been renewed before this step; otherwise, authentication will start to fail for the certificates. Membership in the Enterprise Admins group in the target forest (with write access to the Partitions container object and the cross-reference objects that are its children in the configuration directory partition) and the Local Administrators group (or write access to the domain rename C:\domren working directory) on the control station computer is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477. Note You can use credentials other than the credentials with which you are currently logged on. To use alternative credentials, use the /user and /pwd command-line switches of rendom, as described in Appendix A: Command-Line Syntax for the Rendom Tool. To perform attribute cleanup after a domain rename 1. On the control station, click Start, click Run, type cmd, and then click OK. 2. At the command prompt, type the following command to change to the working directory, and then press ENTER:
C:\domren

3. From within the working directory, type the following command, and then press ENTER:
rendom /clean

The rendom /clean command removes the values for the msDS-DnsRootAlias and msDS-UpdateScript attributes from AD DS by connecting to the domain controller that has the domain naming operations master role. After the steps in this procedure are complete, the new forest is ready for another domain rename (or forest restructuring) operation, if necessary.

Rename Domain Controllers
You can use this procedure to rename domain controllers after a domain rename operation.The Domain Name System (DNS) host names of the domain controllers in the renamed domains do not change automatically as a result of the domain rename operation. In other words, the DNS suffix in the fully qualified DNS host name of a domain controller in the renamed domain continues to reflect

535

the old domain name. You can change the DNS host name of domain controllers in a renamed domain at a later time by using a special procedure. Modification of the computer name causes updates to the DNS and Active Directory databases. The computer performs these updates automatically. After the updated data propagates to the DNS servers and Active Directory domain controllers that a client computer uses, the client computer can locate and authenticate to the renamed domain controller computer. However, DNS and Active Directory replication latency (the time that it takes for the name change to replicate throughout the databases) might cause a temporary inability of clients to locate or authenticate the renamed domain controller. Therefore, renaming a mission-critical server, such as a domain controller, requires that you follow a computer rename preparation procedure before you rename the domain controller. This preparation procedure ensures that there will be no interruption in the ability of client computers to locate or authenticate the renamed domain controller. For more information about how to rename a domain controller, see Renaming a Domain Controller. Note If your forest contains Exchange 2003 Service Pack 1 (SP1) servers, and you chose to rename domain controllers, you must perform several Exchange-specific steps to update the Recipient Update Service and DSAccess registry keys. For more information, see Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup) (http://go.microsoft.com/fwlink/?LinkID=123322).

Additional Resources for the Domain Rename Operation
For more information about the Active Directory domain rename operation, see the following resources: • • • • Appendix A: Command-Line Syntax for the Rendom Tool Appendix B: Command-Line Syntax for the Gpfixup Tool Appendix C: Checklists for the Domain Rename Operation Appendix D: Worksheets for the Domain Rename Operation

Appendix A: Command-Line Syntax for the Rendom Tool
The Rendom command-line tool collects forest-wide information, monitors domain rename status, and performs the actions that are necessary to complete a domain rename operation in your forest. Syntax
rendom [/?] [/dc:{DCNAME | DOMAIN}] [/user:USERNAME] [/pwd:{PASSWORD|*}]

536

[/list] [/upload] [/prepare] [/execute] [/end] [/clean] [/showforest] [/listfile:LISTFILE] [/statefile:STATEFILE] [/logfile:LOGFILE]

Parameter

Description

/? /dc:{DCNAME | DOMAIN}

Optional. Displays the Help and the version number of the tool. Optional. Specifies that the command connect to a specific domain controller, indicated by DCNAME (a Domain Name System (DNS) name or a NetBIOS name), to run the operation that is specified by one of the operation switches: /list, /upload, /prepare, /execute, or /clean. If the name of a domain is specified instead as DOMAIN, the command connects to a domain controller in that domain. Default: When this switch is not specified, connects to any domain controller in the domain to which the computer on which this command is being run belongs. If this command is run on a computer that is not a member of any domain, the /dc switch is required; otherwise, an error is returned.

/user:USERNAME

Optional. Requests that the command run in the security context of a specific user, indicated by USERNAME, that is different from the logged on user. USERNAME can currently be in only one form: domain\user, for example, ntdev\jdow. Optional. Specifies the password for the alternate security context indicated by USERNAME. If the value that is specified for this switch is *, the command prompts for the password to allow hiding of the password. This operation creates a list of the directory partitions in the forest. The list is written as text to a file using an XML format. Therefore, this command creates a textual description of the forest structure using a structured XML format. If a file name is specified with the /listfile switch, below, the forest description is written into that file. If no file name is specified, the forest 537

/pwd:{PASSWORD | *}

/list

Parameter

Description

description is written to a file named DOMAINLIST.XML in the current directory from which this command is run. If the specified file already exists, it is renamed and a new file is created. /upload Performs the following functions: Based on the new forest description that is provided in the file that is created by the /listfile switch (or the file DOMAINLIST.XML in the current directory, by default), this operation generates an instructions file in the form of a special script that will run later on every domain controller in the forest. The instructions file is not a file that is stored on the disk. Writes the autogenerated script (instructions file) to the msDS-UpdateScript attribute of the Partitions container on the domain controller that holds the domain naming operations master role. Sets the msDS DnsRootAlias attribute on the crossRef object that corresponds to every domain that is being renamed. Writes a new state file, indicated by the /statefile switch (or the file DCLIST.XML in the current directory, by default), to track the state of every domain controller in the forest. All domain controllers are marked to be in the Initial state. If the specified file already exists, it is renamed and a new file is created. The forest configuration is frozen for certain types of operations after successful completion of this command. /prepare Attempts to contact every domain controller in the forest (as tracked by the state file), and verifies the following: The correct instructions file (the special script that is uploaded by the /upload operation) has replicated to the domain controller. The changes that are dictated by the instructions file are consistent with the contents of the directory partition replicas that the domain 538

Parameter

Description

controller holds. The domain controller has authorized the running of the domain rename operation. After successful verification of the previous conditions on a given domain controller, the corresponding state for that domain controller is advanced to the Prepared state in the state file. /execute Attempts to contact every domain controller in the forest (as tracked by the state file), and executes the changes that the instructions file dictates to cause the actual domain rename to occur. After successful execution of the instructions file on a given domain controller, the corresponding state in the state file for that domain controller is advanced to Done—a final state that indicates that the restructuring is finished on that domain controller. If an irrecoverable error occurs on a given domain controller, the corresponding state in the state file for that domain controller is set to Error—also a final state, that indicates that the domain controller is not functioning and that it must have Active Directory removed. (That is, it can no longer be used as a domain controller.) The state file that this operation uses is the state file that is specified by the /statefile switch (or the file DCLIST.XML in the current directory, by default). /end Attempts to contact the domain controller that holds the domain naming operations master role of the forest, and removes the msDSUpdateScript attribute on the Partitions container. After successful removal of this attribute on the domain naming master, this operation returns a SUCCESS summary status message. The forest configuration, which was frozen for certain types of operations that follow the /upload operation, is now unfrozen. /clean Attempts to contact the domain controllers that 539

Parameter

Description

holds the domain naming operations master role of the forest, and performs the following functions: Removes all values of the msDS-DnsRootAlias attribute on all crossRef objects in the Partitions container. Removes the msDS-UpdateScript attribute on the Partitions container. After successful removal of these attributes on the domain naming master, this operation returns a SUCCESS summary status message. /showforest Requests that the forest description, which is represented by the list of its directory partitions and their hierarchy), that is contained in the list file be displayed in a user-friendly format with indentation that reflects the domain hierarchy. The list file will typically have been generated by the /list operation of this command. If a file name is specified with the /listfile switch, below, the forest description is read from that file. If no file name is specified, the forest description is assumed to be in a file named DOMAINLIST.XML in the current directory from which this command is being run. If the specified file (or the default file) does not exist, an error is reported with an indication to run the /list operation first. /listfile:LISTFILE Optional. Specifies that LISTFILE is the name of the file that holds the forest description. The list file contains a list of the directory partitions in the forest that is written as text in an XML format. You can use this switch to specify the output file for the /list operation or the input file for the /upload operation. If this switch is not specified, the forest description is assumed to be in a file named DOMAINLIST.XML in the current directory from which this command is being run. /statefile:STATEFILE Optional. Specifies that STATEFILE is the name of the file that is used to track the state of each 540

Parameter

Description

domain controller in the forest during the domain rename operation. The state file contains a list of all the domain controllers in the forest and their corresponding states that is written as text in an XML format. You can use this switch to specify the state file for the /upload, /prepare, and /execute operations. If this switch is not specified, the state of the domain controllers is assumed to be in a file that is named DCLIST.XML in the current directory from which this command is being run. /logfile:LOGFILE Optional. Specifies that LOGFILE is the name of the file that is used to write the execution log of the command as any operation runs. The contents of the log file varies, depending on which operation (/list, /upload, /prepare, /execute, /clean) is running. If this switch is not specified, the execution log is written to a file named RENDOM.LOG in the current directory from which this command is being run.

Appendix B: Command-Line Syntax for the Gpfixup Tool
You can use the gpfixup command-line tool to fix the dependencies that Group Policy objects (GPOs) and Group Policy links in Active Directory Domain Services (AD DS) have on Domain Name System (DNS) and NetBIOS names after a domain rename operation. Syntax
gpfixup [/?] [/v] [/dc:DCNAME] [/user:USERNAME] [/pwd:{PASSWORD|*}] [/olddns:OLDDNSNAME] [/newdns:NEWDNSNAME] [/oldnb:OLDFLATNAME] [/newnb:NEWFLATNAME] [/sionly]

541

Parameter

Description

/? /v

Optional. Displays the Help syntax and the version number of the tool. Optional. Requests that detailed status messages be displayed. In the absence of this switch, only error messages or a brief summary status message of SUCCESS or FAILURE appears. Optional. When the domain rename operation changes the DNS name of a domain, this switch specifies the old DNS name of the renamed domain as OLDDNSNAME, (for example, olddom.contoso.com. You can use this switch if and only if you also use the /newdns switch to provide a new domain DNS name. Optional. When the domain rename operation changes the DNS name of a domain, this switch specifies the new DNS name of the renamed domain as NEWDNSNAME, for example, newdom.contoso.com. You can use this switch to specify the new domain DNS name if and only if you use the /olddns switch to provide the old domain DNS name. Optional. When the domain rename operation changes the NetBIOS name of a domain, this switch specifies the old NetBIOS name of the renamed domain as OLDFLATNAME, for example, olddom. You can use this switch if and only if you use the /newnb switch to provide a new domain NetBIOS name. Optional. When the domain rename operation changes the NetBIOS name of a domain, this switch specifies the new NetBIOS name of the renamed domain as NEWFLATNAME, for example, newdom. You can use this switch to specify the new NetBIOS name of the domain if and only if you use the /oldnb switch to provide the old NetBIOS name of the domain. Optional. Requests that only the Group Policy fix that relates to managed software installation (that is, the SI extension for Group Policy) be 542

/olddns:OLDDNSNAME

/newdns:NEWDNSNAME

/oldnb:OLDFLATNAME

/newnb:NEWFLATNAME

/sionly

Parameter

Description

performed. Skips the actions that fix up the Group Policy links and the SYSVOL paths in the GPOs. /dc:DCNAME Optional. Requests that the command connect to a specific domain controller, indicated by DCNAME (a DNS name or a NetBIOS name), to run the fix-up operation. If DCNAME is specified, it must host a writable replica of the domain directory partition, as indicated by either of the following: The DNS name NEWDNSNAME, using /newdns The NetBIOS name NEWFLATNAME, using /newnb Default: When this switch is not specified, connects to any domain controller in the renamed domain, as indicated by either NEWDNSNAME or NEWFLATNAME. You can use the function DsGetDcName() to obtain a proper domain controller for the given domain. /user:USERNAME Optional. Requests that the command run in the security context of a specific user, indicated by USERNAME, that is different from the logged on user. USERNAME can currently be specified in only one form: domain\user, for example, ntdev\jdow. Optional. Specifies the password for the alternate security context that is indicated by USERNAME. If the value that is specified for this switch is *, the command prompts for the password to allow hiding of the password.

/pwd:{PASSWORD | *}

Appendix C: Checklists for the Domain Rename Operation
This appendix provides checklists for the tasks to be performed during the various phases of the domain rename operation. 543

Complete the tasks in these checklists in the order in which they are presented. If a reference link takes you to a conceptual topic, return to the checklist after you review the conceptual topic so that you can proceed with the remaining tasks.

Satisfying domain rename requirements
This checklist provides the list of requirements that must be met before you can begin a domain rename operation. Checklist: Satisfying domain rename requirements
Task Reference

Adjust the forest functional level. You can rename domains only in a forest in which all the domain controllers are running Windows Server 2008 Standard or Windows Server 2003 Standard Edition, Windows Server 2008 Enterprise or Windows Server 2003 Enterprise Edition, or Windows Server 2008 Datacenter or Windows Server 2003 Datacenter Edition operating systems, and the Active Directory forest functional level has been raised to either Windows Server 2003 or Windows Server 2008. The domain rename operation will not succeed if the forest functional level is set to Windows 2000 native. Obtain the necessary administrative credentials. You must have Enterprise Admins credentials to perform the various steps in the domain rename procedures. If

For more information about forest functional levels and for procedures to determine and set forest functional levels, see Enabling Windows Server 2008 Advanced Features for Active Directory Domain Services (http://go.microsoft.com/fwlink/?LinkID=105303).

The required credentials for each procedure in the domain rename operations are described throughout the topics in Managing Active Directory Domain Rename.

544

Task

Reference

you are running Microsoft Exchange, the account that you use must also have Full Exchange Administrator credentials. Set up the control station. The computer that is to be used as the control station for the domain rename operation must be a member computer (not a domain controller) that is running Windows Server 2008 Standard, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter. Configure Distributed File System (DFS) root servers. If you want to rename a domain with domain-based DFS roots, all DFS root servers must be running Windows 2000 Service Pack 3 (SP3) or a later release of Windows Server, up to Windows Server 2008. Satisfy Exchange-specific requirements: • Exchange 2003 SP1: If your Active Directory forest contains only Exchange 2003 Service Pack 1 (SP1) servers, you can run the domain rename operation, but you must also use the Exchange Domain Rename Fix-up Tool to update Exchange attributes. So that you can For more information, see Distributed File System Technology Center (http://go.microsoft.com/fwlink/?LinkID=18421). Set Up the Control Station

The Exchange Domain Rename Fix-up Tool is available at Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup) (http://go.microsoft.com/fwlink/?LinkID=122982).

545

Task

Reference

perform a domain rename operation, Exchange must not be installed on any domain controllers. If a domain controller is running Exchange, move the Exchange data off the domain controller and uninstall Exchange. • Exchange 2003, Exchange 2000, or Exchange 5.5: The domain rename operation is not supported in an Active Directory forest that contains Exchange Server 2003, Exchange 2000, or Exchange 5.5 servers. If the domain rename tool detects Exchange 2000 servers, the tool will not proceed. The domain rename tool will not detect whether Exchange 5.5 servers exist. Therefore, do not attempt the domain rename operation if the forest contains Exchange 5.5 servers.

Preparing for the domain rename operation
This checklist provides the list of tasks for preparing for the domain rename operation. Checklist: Preparing for the domain rename operation
Task Reference

Adjust the forest functional level. Note

Adjust Forest Functional Level

546

Task

Reference

You can rename domains only in a forest in which all of the domain controllers are running Windows Server 2008 Standard or Windows Server 2003 Standard Edition, Windows Server 2008 Enterprise or Windows Server 2003 Enterprise Edition, or Windows Server 2008 Datacenter or Windows Server 2003 Datacenter Edition operating systems, and the Active Directory forest functional level has been raised to either Windows Server 2003 or Windows Server 2008. The domain rename operation will not succeed if the forest functional level is set to Windows 2000 native. Create necessary shortcut trust relationships within the forest, and document all trusts. • Compile a list of domains to be renamed based on the new forest structure that you want. • Create shortcut trusts, if necessary. • Compile a list of all existing trusts—shortcut, external, and across forests—in the forest. Prepare Domain Name System (DNS) zones. • Compile a list of DNS zones for the domain rename operation. • Create new DNS zones as necessary as a result of the name 547 Prepare DNS Zones Create Necessary Shortcut Trust Relationships

Task

Reference

changes to be performed. Redirect Special Folders to a StandAlone Distributed File System Namespace (DFSN). Relocate Roaming User Profiles to a Stand-Alone DFSN. Prepare member computers for host name changes. Prepare certification authorities (CAs). Prepare a domain that contains Exchange. Redirect Special Folders to a Standalone DFSN Relocate Roaming User Profiles to a Standalone DFSN Configure Member Computers for Host Name Changes Prepare Certification Authorities Exchange-Specific Steps: Prepare a Domain that Contains Exchange

Performing the domain rename operation
This checklist provides the list of tasks that to perform during the core domain rename operation. Checklist: Performing the domain rename operation
Task Reference

Set up your control station for the domain rename operation. Freeze the Forest Configuration Back up all the domain controllers in your forest. Generate the current forest description. Specify the new forest description. Generate domain rename instructions. Push domain rename instructions to all domain controllers, and verify

Set Up the Control Station Freeze the Forest Configuration Back Up All Domain Controllers Generate the Current Forest Description Specify the New Forest Description Generate Domain Rename Instructions Push Domain Rename Instructions to All Domain 548

Task

Reference

DNS readiness. Verify the readiness of the domain controllers. Execute the domain rename instructions. Update the Exchange configuration, and restart the Exchange servers. Note This is an optional, Exchange-specific task. Unfreeze the forest configuration. Re-establish external trusts. Fix Group Policy objects (GPOs) and links.

Controllers and Verify DNS Readiness Verify Readiness of Domain Controllers Run Domain Rename Instructions Exchange-Specific Steps: Update the Exchange Configuration and Restart Exchange Servers

Unfreeze the Forest Configuration Re-establish External Trusts Fix Group Policy Objects and Links

Completing the domain rename operation
This checklist provides a list of tasks that have to be performed after the core domain rename procedures are complete. Some tasks may be optional, depending on your situation and business needs. Checklist: Completing the domain rename operation
Task Reference

Verify certificate security. Perform certain miscellaneous procedures. Back up domain controllers. Restart all member computers. Verify the Exchange rename, and update Active Directory Connector.

Verify Certificate Security Perform Miscellaneous Tasks Back Up Domain Controllers Restart Member Computers Exchange-Specific Steps: Verify the Exchange Rename 549

Task

Reference

Note This is an optional, Exchange-specific step. Perform attribute cleanup. Rename domain controllers.

and Update Active Directory Connector

Perform Attribute Cleanup Rename Domain Controllers

Appendix D: Worksheets for the Domain Rename Operation
This section includes worksheets in suggested formats that you can to gather information about your Active Directory infrastructure. You can use these worksheets to prepare for the domain rename operation and to track progress as you perform the operation.

Worksheet 1: Domain Name Change Information
You can use this worksheet to create a list of name changes that will be completed during your domain rename operation. List changes for all forests and domains and all application directory partitions.
Old NetBIOS name Old DNS name New NetBIOS name New DNS name

1 2 3 4 5

Worksheet 2: Trust Information
You can use this worksheet to document all trust relationships (for shortcut trusts and external trusts) and the status of each trust that has to be created or removed during the domain rename operation.

550

Trusting domain name

Trusted domain name

Trust direction

Trust type

Date created/removed

1 2 3 4 5

Worksheet 3: DNS Zone Information
You can use this worksheet to list all Domain Name System (DNS) zones that must be added in preparation for the domain rename operation.
DNS zone name Add/remove Completed? Date/time

1 2 3 4 5

Worksheet 4: DFSN, Folder Redirection, and Roaming Profiles
You can use this worksheet to document all domain Distributed File System Namespaces (DFSN) paths, including the paths that are used by folder redirection and roaming profiles. All domain DFSN paths will require reconfiguration after the domain rename operation is complete.
Domain name Old domain DFSN path New domain DFSN path Server share path for folder redirection and roaming profiles Group Policy updated? Date/time? DFSN fixed? Date/time?

1 2 3 551

Domain name

Old domain DFSN path

New domain DFSN path

Server share path for folder redirection and roaming profiles

Group Policy updated? Date/time?

DFSN fixed? Date/time?

4 5

Worksheet 5: Domain Controller Information
You can use this worksheet to document information about specific domain controllers, including information about operations master roles (also known as flexible single master operations or FSMO roles).
Domain DC name IP address FSMO roles held by DC CRL expiry Execute successfully? Automatic restart? Dcdiag notes

1 2 3 4 5

Worksheet 6: Domain Rename Execution Readiness
You can use this worksheet to track the readiness of domains, forests, and application partitions before the beginning of the domain rename operation. You can also use the information in this worksheet to check the forest description before you proceed.
Domain/application partition Run Dcdiag? Backed up? DNS zone ready?

1 2 3 552

Domain/application partition

Run Dcdiag?

Backed up?

DNS zone ready?

4 5

Worksheet 7: Certification Authority (CA) Information
You can use this worksheet when you enable certificate enrollment in a renamed domain.
Old DNS name of CA New DNS name of CA Alias created? Date/time Certificate enrollment enabled? CDP and AIA extensions flexible? Subordinate and issuing CA certs renewed? Group Policy updated?

1 2 3 4 5

Additional Resources
For general information about how Active Directory Domain Services (AD DS) works and how to deploy, manage, and troubleshoot AD DS, see the following resources: • • • Active Directory Domain Services (http://go.microsoft.com/fwlink/?LinkId=96418) AD DS Design Guide (http://go.microsoft.com/fwlink/?LinkId=100493) AD DS Deployment Guide (http://go.microsoft.com/fwlink/?LinkId=116283)

• Best Practices for Delegating Active Directory Administration (http://go.microsoft.com/fwlink/?LinkId=46579) • Active Directory Script Center (http://go.microsoft.com/fwlink/?LinkId=122875) For specific information about troubleshooting Active Directory problems, see the following resources: • • Troubleshooting: AD DS (http://go.microsoft.com/fwlink/?LinkId=122878) Directory Services Community (http://go.microsoft.com/fwlink/?LinkId=20151) 553

For development information about Active Directory, see the following resources: • Active Directory Domain Services (http://go.microsoft.com/fwlink/?linkid=142) • Lightweight Directory Access Protocol (LDAP) (http://go.microsoft.com/fwlink/? LinkID=2972) • Request for Comments (RFC) Pages and Internet-Drafts on the Internet Engineering Task Force Web site (http://go.microsoft.com/fwlink/?LinkID=121)

Active Directory Domain Services Operations Guide - cover
Insert introduction here.

Section Heading
Insert section body here.

Subsection Heading
Insert subsection body here.

554

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close