Вы находитесь на странице: 1из 554

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 optionTwo-way........................................................................................................84 Wizard optionOne-way: incoming........................................................................................85 Wizard optionOne-way: outgoing.........................................................................................86 Sides of trust..............................................................................................................................87 Wizard optionThis domain only............................................................................................87 Wizard optionBoth 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 errorsnonauthoritative restore..................................................226 Solutions for data lossauthoritative 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 twiceonce 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 2008based domain whose users want to gain access to resources that are stored in a Windows NTbased domain, you must create a trust relationship in which the Windows NTbased domain trusts the users from the Windows Server 2008based domain. In this case, the Windows NTbased domain is the trusting domain, and the Windows Server 2008based domain is the trusted domain. You can create an external trust between two Windows Server 2003based or Windows Server 2008based domains, between a Windows Server 2008based domain and a Windows Server 2003based domain, or between a Windows Server 2003based domain or Windows Server 2008based domain and a Windows NTbased 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 designedor that communications over the trust are workingby 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 administrators 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 organizations forest to a limited set of users in another organizations forest. For more information about how selective authentication settings work, see Security Considerations for Trusts (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 routedwithout restrictionover 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 routedwithout restrictionover 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 optionTwo-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 optionOne-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 optionOne-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 incrementallyone 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 optionThis 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 twiceonce 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 optionBoth 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 2003based computer or a Windows Server 2008based 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 datain 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 preWindows 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 computers 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 datain 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 sourceperhaps because it was formerly not joined to the domainyou 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 domains 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 areaswhich 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 Directoryenabled 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 controllers 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 controllers priority in the DNS environment so that it processes client requests only if other DNS servers are unavailable. With fewer DNS client requests to process, the domain controller can use more resources to perform operations master services for the domain. 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 users 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 Directoryenabled clients. As the network grows, the volume of client requests can increase the workload for the domain controller that hosts the PDC emulator role and its performance can suffer. To solve this problem, you can transfer all or some of the 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 holderusually, 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 onlinefor 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 backupswhich are essential for dependable operationsand 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 Directoryintegrated. You must be aware of the location of DNS zones and back up DNS servers accordingly. If you use Active Directoryintegrated DNS, DNS zone data is captured as part of system state and critical-volume backups on domain controllers that are also DNS servers. 210

If you do not use Active Directoryintegrated 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: Whats 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 Directoryintegrated 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 Directoryintegrated 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 errorsnonauthoritative 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 lossauthoritative 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 copycreated 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 groupsglobal groups, domain local groups, and universal groupsglobal 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 backupare 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 membershipsor any other unwanted object attributecomplete 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 restoredor whose members are being restoredare 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. Howeverof particular importance where group memberships are concernedthe 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 deletionsand in any other domains that might have group memberships for the deleted accountsto 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 asor larger thanthe 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 users 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 users domain and the identity of the users 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 users 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 controllers 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